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Forord 

Det ar en svar uppgift att dokumentera, beskriva och definiera en begreppsvarld som 
anvands inom ett speciellt omrade. Det finns alltid olika uppfattningar om vilka termer som 
verkligen anvands eller vilka termer som bor anvandas. Ordlistor for terminologi inom 
programvarutestning som finns tillgangliga i dag ar ofta pa annat sprak an svenska eller 
begransar sig inte till omradet programvarutestning. 

Arbetet med att framstalla denna ordlista har fokuserat pa att ordlistan ska innehalla 
vanligt fdrekommande ord som anvands av testare inom Sverige saval som i ovriga varlden, 
men att orden i storst mojliga man ska vara pa svenska. Dock ar det inte alltid som en 
svensk oversattning ar lamplig; i dessa fall bor det engelska ordet aven i fortsattningen 
anvandas. Vid diskussioner om val av ord och eventuella oklarheter i definition har hansyn 
tagits till synpunkter fran olika omraden dar programvarutestning ar en del av eller ar den 
huvudsakliga utovningen. Exempel pa foretag och omraden ar konsultforetag inom 
programvarutestning, bankvarlden, utbildningsforetag och forskning inom den akademiska 
varlden. Vid val av ord och definition har dock storst vikt lagts vid de standarder som finns 
i dag. 

En utav de mest anvanda standarder inom programvarutestning ar och har 
varit ”BS 7925-2:1998, Software Component Testing”. Det finns tva nackdelar: standarden 
ar skriven utifran ett komponentbaserat perspektiv och under de ar som standarden har 
funnits har det getts kommentarer pa fdrbattringar i befintliga definitioner och fdrslag pa 
nya definitioner. ” Standard Glossary of Terms used in Software Testing, Version 2.0”, ar den 
ordlista som internationellt ersatter BS 7925-2. Denna ordlista utgar ifran och ar en 
oversattning av terminologi i 

’’Standard Glossary of Terms used in Software Testing, Version 2.3.” 

Introduktion 

Att det ar viktigt att bli forstadd nar man kommunicerar med kolleger inom sitt yrke ar 
sjalvklart for alia. Lika viktigt ar det att bli forstadd vid kommunikation utanfdr sitt 
yrkesomrade. Exempel pa sadan kommunikation ar kontakt med kunder och andra 
yrkesgrupper eller kommunikation mellan intressenter inom industri och den akademiska 
varlden. 

Om missforstand uppstar kan det bero pa att deltagarna har olika uppfattningar om vad ord 
betyder och vilken definition som bor anvandas for ordet. Sadana missforstand kan leda till 
okade kostnader och tvetydigheter i skrivna dokument. Darfor ar det viktigt att 
kommunikationen utgar fran en gemensam terminologi. 

Syftet med denna ordlista ar att den ska kunna anvandas som underlag for en gemensam 
svensk terminologi vid kommunikation dar det annars ar risk for missforstand mellan 
intressenter. 


Omfattning 


Terminologin i denna ordlista ar begransad till: 

• terminologi som anvands i ISTQB/ SSTB kursplanfor certifierad testare grundniva 
version 2007 utgiven av Swedish Software Testing Board, SSTB, en del av ISTQB 

• terminologi som anvands vid kommunikation mellan intressenter inom omradet 
programvarutestning och relaterade discipliner 
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Disposition 


Ordlistan ar uppbyggd enligt foljande mall: 

Nyckelord 
Term: Forklaring. 

Kommentar. Fortydligande. 

Nyckelord: ISTQB Glossary (och ordlista) innehaller termer av olika skal. Nagra firms bara 
for att stodja lasaren av en Syllabus (eller kursplan) att fdrsta en text. Nagra firms dar helt 
enkelt for att termen anvandes i en tidigare version av en Syllabus och principen for 
bakatkompatobilitet har anvants. Men troligen ar de viktigate termerna de som ar explicit 
definierade i olika ISTQB-Syllabi (kursplaner) och ar underlag for examinering. En viktig 
malgrupp for dessa nyckelord ar den testverksamme som forbereder sig for en tentamen. 

For att stodja dessa visar nyckelorden for vilken examen termen ar tillampbar. Notera ocksa 
att arvsprincipen galler, t.ex. vid en ISTQB-examen pa Advanced Level ska man fortfarande 
forsta termer enligt nyckelord pa Foundation Level. 

Nyckelorden har oljande benamningar: 

F: ISTQB Foundation syllabus 

F-AT: ISTQB Foundation Extension Agile Tester syllabus 

ATM: ISTQB Advanced - Test Management syllabus 

ATA: ISTQB Advanced - Test Analyst syllabus 

ATT: ISTQB Advanced - Technical Test Analyst syllabus 

EITP: ISTQB Expert - Improving the Testing Process syllabus 

ETM: ISTQB Expert - Test Management syllabus. 

Term: det ord som fdrklaras. 

Forklaring: en beskrivande text (definition) som fdrklarar ordet. En forklaring kan vara en 
hanvisning till ett annat ord. Definitionen galler da for alia de ord som kan fdljas via 
hanvisningen och orden kan anvandas som synonymer. Exempel: acceptans: Se 
acceptanstestning. 

I borjan pa en forklaring kan ett eller flera alternativa ord finnas angivna. Exempel pa 
alternativt ord ar: 

• ett ord som ar mindre forekommande men anda tillrackligt viktigt for att namnas i 
ordlistan: 

o awikelse: aven incident, ... 

• ett ord dar det finns ett svenskt ord men en oversattning ar olamplig (aven 
motsatsen kan galla har, en oversattning till svenskt ord kan goras men ett engelskt 
kan ocksa anvandas): 


o finess: aven feature, ... 


I slutet av en forklaring kan ett eller flera relaterade ord finnas angivna. Ett relaterat ord ar 
ett ord som satter det fdrklarade ordet i ett sammanhang for okad tydlighet. Exempel: 
feltolerans: ... Se aven tillforlitlighet. 

Kommentar. ett fortydligande dar: 

• det allmant forekommer missuppfattningar, 

• det finns tvetydigheter i hur terminologin anvands, 

• det finns skillnader i hur terminologin anvands i Sverige jamfort med ovriga lander. 
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Normgivande referenser 

Nedanstaende referenser har anvants som utgangsmaterial for denna ordlista. Dessa 
referenser var vid publicering av denna ordlista de senast gallande. Vid anvandning av 
denna ordlista bor hansyn tas till om det har utkommit nyare versioner av nedanstaende 
standarder. 

- BS 7925-2:1998. Software Component Testing 

- DO-178B: 1992. Software Considerations in Airborne Systems and Equipment 
Certification, Requirements and Technical Concepts for Aviation (RTCA SC 167) 

- IEEE 610.12:1990. Standard Glossary of Software Engineering Terminology 

- IEEE 829:1998. Standard for Software Test Documentation 

- IEEE 1008:1993. Standard for Software Unit Testing 

- IEEE 1012:1986. Standard for Verification and Validation Plans 

- IEEE 1028:1997. Standard for Software Reviews and Audits 

- IEEE 1044:1993. Standard Classification for Software Anomalies 

- IEEE 1219:1998. Software Maintenance 

- ISO/IEC 2382-1:1993. Data processing - Vocabulary - Part 1: Fundamental terms 

- ISO 9000:2000. Quality Management Systems - Fundamentals and Vocabulary 

- ISO/IEC 9126-1:2001. Software Engineering - Software Product Quality -Part 1: 
Quality characteristics and sub-characteristics 

- ISO/IEC 12207:1995. Information Technology - Software Life Cycle Processes 

- ISO/IEC 14598-1:1996. Information Technology - Software Product Evaluation - Part 
1: General Overview 


Varumarken 

I detta dokument anvands foljande registrerade varumarken: 

- CMM och CMMI ar registrerade varumarken av Carnegie Mellon University 

TMap, TPA, TPI och TPI Next ar registrerade varumarken av Sogeti Nederland BV 
TMM ar registrerat varumarke av Illinois Institute of Technology 
TMMi ar registrerat varumarke av TMMi Foundation 


Definitioner 


A 


abstract test case: See high level test case. 

abstrakt testfall: Se hognivatestfall. 


acceptance: See acceptance testing. 

acceptans: Se acceptanstestning. 


acceptance criteria: The exit criteria that a component or 
system must satisfy in order to be accepted by a user, 
customer, or other authorized entity. [IEEE 610] 

acceptanskriterier: De sluttillstand eller krav som en 
komponent eller ett system ska uppna for att 
accepteras av en anvandare, kund eller annan 
auktoriserad person eller organisation. [IEEE 610] 
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acceptance testing: Formal testing with respect to user 
needs, requirements, and business processes conducted 
to determine whether or not a system satisfies the 
acceptance criteria and to enable the user, customers or 
other authorized entity to determine whether or not to 
accept the system. [After IEEE 610] 

acceptanstestning: Formell testning med inriktning 
pa anvandarbehov, anvandarkrav och anvandarens 
verksamhet. Avsikten ar att bedoma om ett system 
uppfyller acceptanskriterier och for att ge 
anvandare, kunderoch annan auktoriserad person 
eller organisation mojlighet att acceptera systemet. 
[Efter IEEE 610] 

ATA 

accessibility testing: Testing to determine the ease by 
which users with disabilities can use a component or 
system. [Gerrard] 

tillganglighetstestning (accessibility testing): 

Testning for att faststalla hur lattanvant 
komponenten eller systemet ar for manniskor med 
funktionshinder. [Gerrard] 

Se aven tillganglighet 


accuracy: The capability of the software product to 
provide the right or agreed results or effects with the 
needed degree of precision. [ISO 9126] See also 
functionality. 

exakthet: aven precision, noggrannhet. Mojligheten, 
formagan hos systemet (inkluderat programvara, 
data och hardvara) att erbjuda ratt och exakt det 
resultat och den effekt som efterstravas. [ISO 9126] 

Se aven funktionalitetstestning. 

ATA 

accuracy testing: The process of testing to determine the 
accuracy of a software product. 

See also accuracy. 

noggrannhetstestning: Den testaktivitet som ska 
sakerstalla noggrannheten hos en 
programvaruprodukt. 

Se aven exakthet. 

EITP 

acting (IDEAL): The phase within the IDEAL model where 
the improvements are developed, put into practice, and 
deployed across the organization. The acting phase 
consists of the activities: create solution, pilot/test 
solution, refine solution and implement solution. See also 

IDEAL. 

agerande (IDEAL): Den fas inom IDEAL modellen i 
vilken forbattringar identifieras, utvecklas och 
genomfors inom organisationen. Agerande-fasen 
bestir av aktiviteterna: skapa losning, utvardera 
losning, forfina losning och implementera losning. Se 

aven IDEAL. 


action word driven testing: See keyword-driven testing 

aktionsord-driven testning: Se nyckelordsdriven 
testning. 


actor: User or any other person or system that interacts 
with the system under test in a specific way. 

aktor: Anvandare, annan person eller system som 
samspelar med systemet som testas pa ett 
specificerat satt. 


actual outcome: See actual result. 

faktiskt utfall: Se faktiskt resultat. 


actual result: The behavior produced/observed when a 
component or system is tested. 

faktiskt resultat: Det resultat som produceras eller 
observeras naren komponent eller ett system 

testas. 


ad hoc review: See informal review. 

ad hoc-granskning: Se informell granskning. 


ad hoc testing: Testing carried out informally; no formal 
test preparation takes place, no recognized test design 
technique is used, there are no expectations for results 
and arbitrariness guides the test execution activity. 

ad hoc-testning: aven slumpmassig testning. 

Testning dar man inte anvander nagon speciell 
testteknik, metod, forberedelse eller forvantat 
resultat, utan slumpen avgor vad som testas. 
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ATT 

adaptability: The capability of the software product to be 
adapted for different specified environments without 
applying actions or means other than those provided for 
this purpose for the software considered. [ISO 9126] See 
also portability. 

anpassningsbarhet: Programvaruproduktens 
kapacitet att anpassas till olika omgivningar och 
miljoer utan att programvaran behoverandras 
namnvart pa programvaran. [ISO 9126] Se aven 
flyttbarhet. 


agile manifesto: A statement on the values that underpin 
agile software development. The values are: 

- individuals and interactions over processes and tools 

- working software over comprehensive documentation 

- customer collaboration over contract negotiation 

- responding to change over following a plan. 

agilt manifest: En beskrivning av de gemensamma 
varden som all agil programvaruutveckling vilar pa: 

- Individer och samspel framfor metoder, processer 
och verktyg 

- Korbar programvara framfor omfattande 
dokumentation 

- Kundsamarbete framfor kontraktsforhandlingar 

- Anpassning till forandring framfor foljandet av en 
plan. 

EITP 

agile software development: A group of software 
development methodologies based on iterative 
incremental development, where requirements and 
solutions evolve through collaboration between self¬ 
organizing cross-functional teams. 

agil programvaruutveckling: En grupp av 
programvaruutvecklingsmetoder baserade pa 
iterativ, inkrementell utveckling, dar kravoch 
losningar vaxer fram genom samarbete mellan 
sjalvorganiserande tvarfunktionella team. 

EITP 

agile testing: Testing practice for a project using agile 
software development methodologies, incorporating 
techniques and methods, such as extreme programming 
(XP), treating development as the customer of testing and 
emphasizing the test-first design paradigm. See also test 
driven development. 

agil testning: Ett tillvagagangssatt for test i ett 
projekt som anvander agila 

programutvecklingsmetodiker, inklusive teknikeroch 
metoder, som exempelvis extreme programming 
(XP), dar utveckling ses som avnamare till test och 
betonar paradigmet testa forst. Se aven testdriven 
utveckling. 


algorithm test: [TMap] See branch testing. 

algoritmstyrd testning: [TMap] Se bagtestning. 

F 

alpha testing: Simulated or actual operational testing by 
potential users/customers or an independent test team at 
the developers' site, but outside the development 
organization. Alpha testing is often employed for off-the- 
shelf software as a form of internal acceptance testing. 

alfatestning: Simulerad eller verklig driftstestning av 
potentiella anvandare, kunder eller ett oberoende 
testteam hos leverantoren, men utanfor 
utvecklingsorganisationen. Alfatestning anvands ofta 
for standardprogramvara som en form av intern 
acceptanstestning hos leverantoren. 

ETM 

analytical testing: Testing based on a systematic analysis 
of e.g., product risks or requirements. 

analytisk testning: Testning baserat pa en 
systematisk analys av t.ex. produktrisker eller krav. 

ATT 

analyzability: The capability of the software product to be 
diagnosed for deficiencies or causes of failures in the 
software, or for the parts to be modified to be identified. 
[ISO 9126] See also maintainability. 

analyserbarhet: Mojligheten att avgora felorsak i ett 
system genom att diagnosticera av avvikelser eller 
orsakertill felsymptom, d.v.s. lokalisera fel i 
programvaran, och darmed gora en specifik rattning 
av felet utan att infora sidoeffekter. [ISO 9126] Se 

aven underhallbarhet. 


analyzer: See static analyzer. 

analysverktyg: Se verktyg for statisk analys. 
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ATM 

anomaly: Any condition that deviates from expectation 
based on requirements specifications, design documents, 
user documents, standards, etc. orfrom someone's 
perception or experience. Anomalies may be found during, 
but not limited to, reviewing, testing, analysis, 
compilation, or use of software products or applicable 
documentation. [IEEE 1044] See also bug, defect, 
deviation, error, fault, failure, incident, problem. 

anomali: Nagot tillstand som avvikerfran det 
forvantade, vilket baseras pa exempelvis 
kravspecifikationer, designspecifikationer, 
anvandardokumentation, standarder alternativt 
personliga uppfattningar eller erfarenheter. 

Anomalier kan hittas vid t.ex. granskning, testning, 
analys, kompilering, eller anvandning av 
programvaruprodukt eller tillhorande 
dokumentation. [IEEE 1044] Se aven defekt, 
avvikelse, fel, felsymptom, incident, problem. 



Kommentar: Se mer information om felsymptom. 
Speciellt anvands termen av IEEE om feltyper inom 
manga yrkesgrenar. Det ar ett bra samlingsbegrepp 
for asikter, avvikelser och felsymptom, som annu 
inte ar klassificerade. Se IEEE Std. 1012 och IEEE Std. 

1044. 

ATT 

anti-pattern: Repeated action, process, structure or 
reusable solution that initially appears to be beneficial and 
is commonly used but is ineffective and/or 
counterproductive in practice. 

anti-monster: Upprepad handling, process, struktur 
eller ateranvandbar losning som fran borjan verkar 
vara till nytta och anvands ofta, men ar ineffektiv 
och/eller kontraproduktiv i praktiken. 


API (Application Programming Interface) testing: Testing 

the code which enables communication between different 

processes, programs and/or systems. API testing often 
involves negative testing, e.g., to validate the robustness 
of error handling. See also interface testing. 

API-testning: Testa den kod som mdjliggor 
kommunikation mellan olika processer, program 
och/eller system. API-testning innebarofta negativa 
tester, t.ex. for att validera stabiliteten i felhantering. 
Se aven granssnittstestning. 


arc testing: See branch testing. 

bagtestning: Se eng. "branch testing". 

EITP 

assessment report: A document summarizing the 
assessment results, e.g. conclusions, recommendations 
and findings. See also process assessment. 

utvarderingsrapport: Ett dokument som 
sammanfattar resultaten av en utvardering, d.v.s. 
slutsatser, rekommendationer och observationer. Se 
aven processutvardering. 

EITP 

assessor: A person who conducts an assessment; any 

member of an assessment team. 

utvarderare: Person som genomfor en utvardering; 
medlem i ett utvarderingsteam. 

ATT 

atomic condition: A condition that cannot be 

decomposed, i.e., a condition that does not contain two or 
more single conditions joined by a logical operator (AND, 

OR, XOR). 

odelbart villkor: Ett tillstand som inte kan brytas 
ned, dvs. ett tillstand som inte innehallertva eller 
flera enkla villkor forenade med en logisk operator 
(AND, OR, XOR). 

F 

attack: Directed and focused attempt to evaluate the 
quality, especially reliability, of a test object by attempting 
to force specific failures to occur. See also negative 
testing. 

attack: Ett forsok, inriktat pa att utvardera kvaliteten 
hos ett testobjekt genom att framtvinga specifika 
felsymptom. Se aven negativ testning. 
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attack-based testing: An experience-based testing 
technique that uses software attacks to induce failures, 
particularly security related failures. See also attack. 

attackbaserad testning: En erfarenhetsbaserad 
testteknik dar man anvander sig av 
programvarubaserade attacker for att framkalla fel, i 
synnerhet sakerhetsrelaterade fel. Se aven attack. 

ATA 

attractiveness: The capability of the software product to 
be attractive to the user. [ISO 9126] See also usability. 

tilltalande: En egenskap hos ett program eller 
system som innebar att programmet eller systemet 
ar tilltalande for anvandaren. [ISO 9126] Seaven 

anvandbarhet. 

ATM 

audit: An independent evaluation of software products or 
processes to ascertain compliance to standards, 
guidelines, specifications, and/or procedures based on 
objective criteria, including documents that specify: 

(1) the form or content of the products to be produced 

(2) the process by which the products shall be produced 

(3) how compliance to standards or guidelines shall be 
measured. [IEEE 1028] 

revision: aven audit. 

Oberoende granskning med syfte att kontrollera att 
bestamda aktiviteter har utforts pa ratt satt enligt 
givna instruktioner, standarder, specifikationer eller 
procedurer baserat pa objektiva kriterier som 
specificerar: 

(1) format och innehall hos den producerade 
produkten 

(2) processen som styr produktionen av produkten 

(3) hur standarder och riktlinjer skall tillmotesgas. 

[IEEE 1028] 


audit trail: A path by which the original input to a process 
(e.g. data) can be traced back through the process, taking 
the process output as a starting point. This facilitates 
defect analysis and allows a process audit to be carried 
out. [AfterTMap] 

revisionsspar: aven revisionsvag. En uppfoljningsvag 
i en process dar man kan spara tillbaka till 
ursprungsindata genom hela processen. Detta 
underlattarfelanalys och processrevision. [Efter 

TMap] 


automated testware: Testware used in automated testing, 
such as tool scripts. 

automatiserad testvara: Testvara som anvands i 

automatiserad testning, t.ex. testskript. 


availability: The degree to which a component or system 
is operational and accessible when required for use. Often 
expressed as a percentage. [IEEE 610] 

tillganglighet: Den grad till vilken en komponent 
eller ett system ar i drift och tillgangligt for 
anvandning. Uttrycks ofta i procent. [IEEE 610] 

Se aven tillganglighetstestning (accessibility testing) 


B 



back-to-back testing: Testing in which two or more 
variants of a component or system are executed with the 
same inputs, the outputs compared, and analyzed in cases 
of discrepancies. [IEEE 610] 

sida-vid-sida testning: Testning dartva eller flera 
varianter av komponenter eller system exekveras 
med samma invarden, varefter man jamfor utvarden 
och analyserarskillnaderna. [IEEE 610] 

EITP 

balanced scorecard: A strategic tool for measuring 
whether the operational activities of a company 
are aligned with its objectives in terms of 
business vision and strategy. See also corporate 
dashboard, scorecard. 

balanserat styrkort: Ett strategiskt 
prestandamatningsverktyg som anvands for att 
undersoka huruvida ettforetags aktiviteter ar i linje 
med dess mal i termer av affarsvision och strategi. Se 
aven corporate dashboard, dashboard och styrkort. 
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baseline: A specification or software product that has 
been formally reviewed or agreed upon, that thereafter 
serves as the basis for further development, and that can 
be changed only through a formal change control process. 
[After IEEE 610] 

faststalld konfiguration: Sammanfattande begrepp 
for att publicera ingaende granskade delar i ett 
system och delarnas versioner. Denna konfiguration 
fungerar sedan som grund for vidare utveckling och 
kan endast andras efter en formell andringsprocess. 
[Efter IEEE 610] 


basic block: A node in a control flow graph represents a 

basic block. 

basblock: En nod i en kontrollflodesgraf 
representerarett basblock. 


basis test set: A set of test cases derived from the internal 

structure of a component or specification to ensure that 
100% of a specified coverage criterion will be achieved. 

komplett tackningsmangd: En mangd avtestfall som 
skapas baserat pa den interna strukturen hos en 
komponent eller specifikation for att sakerstalla att 

100 % tackningsgrad for ett specificerat 
tackningskriterium uppnas. 


bebugging: [Abbott] See fault seeding. 

nedlusning: Se felinjektion. [Abbott] 


behavior: The response of a component or system to a set 
of input values and preconditions. 

beteende: Komponentens eller systemets svar pa en 
uppsattning av invarden och forutsattning. 


benchmark test: (1) A standard against which 
measurements or comparisons can be made. (2) A test 
that is be used to compare components or systems to 
each other or to a standard as in (1). [After IEEE 610] 

typprov: (1) En standard med vilken matningaroch 
jamforelser kan goras. 

(2) En test som anvands for att jamfora 
komponenter eller system med varandra eller med 
en standard som i (1). [Efter IEEE 610] 

Kommentar: Till exempel testning av protokoll vid 
datakommunikation, sasom SEMCO. 


bespoke software: Software developed specifically for a 
set of users or customers. The opposite is off-the-shelf 

software. 

kundanpassad programvara: Programvara utvecklad 
specifiktfor vissa anvandare eller kunder. Motsatsen 
ar standardprogramvara. 


best practice: A superior method or innovative practice 
that contributes to the improved performance of an 
organization under given context, usually recognized as 
'best' by other peer organizations. 

best practice: En overlagsen metod eller ett 
uppfinningsrikt arbetssatt som bidrartill en 
forbattrad prestation inom en organisation. Bygger 
pa en erfarenhetsbaserad bedomning gallande vilket 
av flera mojliga arbetssatt/angreppssatt som leder 
fram till avsett resultat. 
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F 

beta testing: Operational testing by potential and/or 
existing users/customers at an external site not otherwise 
involved with the developers, to determine whether or 
not a component or system satisfies the user/customer 
needs and fits within the business processes. Beta testing 
is often employed as a form of external acceptance testing 
for off-the-shelf software in order to acquire feedback 
from the market. 

betatestning: aven falttestning. Driftstestning som 
utfors pa plats hos slutkund eller slutanvandare dar 
man later kunden vara en del av 

"testorganisationen". Syftet ar attta reda pa om en 
komponent eller ett system uppfyller 
anvandarens/kundens behov och passar in i den 
verksamhet som det ska anvandas i. 

Kommentar: Notera att det kan forekomma att 

betatestning anvands synonymt med 
acceptanstestning, men syftet med ett betatest 
behover inte vara acceptanstestning. 


big-bang testing: An integration testing approach in which 
software elements, hardware elements, or both are 
combined all at once into a component or an overall 
system, rather than in stages. [After IEEE 610] See also 
integration testing. 

big-bangtestning: En integrationstestningsstrategi 
dar alia komponenter av ett system testas 
tillsammans pa en gang utan att ha 
integrationstestats i mindre delar innan, t.ex. som 
delsystem i forvag. [Efter IEEE 610] Se aven 
integrationstestning. 


black box technique: See black box test design technique. 

black-box-teknik: Se black-box-testdesignteknik. 

F 

ATA 

black box test design technique: Procedure to derive 
and/or select test cases based on an analysis of the 
specification, either functional or non-functional, of a 
component or system without reference to its internal 

structure. 

black-box-testdesignteknik: Procedur for att skapa 
och valja testfall for en komponent eller ett system 
utan referens till dess interna struktur. En black-box- 

testdesignteknik bygger pa analys av specifikationen 
som kan vara funktionell eller icke-funktionell. 

Kommentar: Kallas aven specifikationsbaserad 
teknik, vilket bland annat omfattar 
ekvivalensklassindelning, testning med hjalp av 
beslutstabeller, tillstandsbaserad testning och 
anvandningsfallsbaserad testning. 

F 

black box testing: Testing, either functional or non¬ 
functional, without reference to the internal structure of 
the component or system. 

black-box-testning: Testning, funktionellt eller icke- 
funktionellt, utan referens till den interna strukturen 
hos en komponent eller ett system. 

Kommentar: Test som utfors UTAN vetskap om hur 
ett system eller en komponent ar uppbyggd eller vad 
det bestar av. Det engelska ordet ar ett inarbetat 
begrepp. 


blocked test case: A test case that cannot be executed 

because the preconditions for its execution are not 
fulfilled. 

blockerat testfall: Ett testfall som inte kan 

exekveras, darfor att forutsattningarna for testfallet 
inte ar uppfyllda. 
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bottom-up testing: An incremental approach to 
integration testing where the lowest level components are 
tested first, and then used to facilitate the testing of 
higher level components. This process is repeated until the 
component at the top of the hierarchy is tested. See also 
integration testing. 

nerifran och upp-testning: aven bottom-up-testning. 
En inkrementell integrationstestteknik, dar 
komponenterna pa den lagsta nivan testas forst, 
darefter sker en successiv integration och testning av 
systemet i nivaer. Processen upprepas tills alia 
komponenter har integrerats till ett system pa 
hogsta nivan. Se aven integrationstestning, uppifran 
och ner-testning. 


boundary value: An input value or output value which is 
on the edge of an equivalence partition or at the smallest 
incremental distance on either side of an edge, for 
example the minimum or maximum value of a range. 

gransvarde: In- eller utvarde som befinner sig pa 
gransen till en ekvivalensindelning, eller pa det 
minsta avstandetfran nagon av granserna, t.ex. ett 
min- eller maxvarde for ett omrade. 

F 

ATA 

boundary value analysis: A black box test design 
technique in which test cases are designed based on 
boundary values. See also boundary value. 

gransvardesanalys: En black-box-testdesignteknik 

som anvands for att utveckla testfall som avser att 

testa gransvarden. Se aven gransvarde. 


boundary value coverage: The percentage of boundary 
values that have been exercised by a test suite. 

gransvardestackning: Den procentuella 
tackningsgraden av gransvarden som har exekverats 

av en testsvit. 


boundary value testing: See boundary value analysis. 

gransvardestestning: Se gransvardesanalys. 


branch: A basic block that can be selected for execution 
based on a program construct in which one of two or 
more alternative program paths is available, e.g. case, 
jump, go to, ifthen- else. 

kodgren: aven exekveringsvag. Ett basblock i ett 
program som kan valjas for exekvering dar en av tva 
eller flera alternativa exekveringsvagar ar mojliga, 
t.ex. case, jump, goto och if-then-else. 


branch condition: See condition. 

kodgrensvillkor: Se villkor. 

Kommentar: Ett villkor styrvilken kodgren 
(exekveringsvag) som skall valjas, och handlarom att 
testa utfallen av villkoret. 


branch condition combination coverage: See multiple 
condition coverage. 

kodtackning av kombinationer av kodgrenvillkor: Se 

kombinationsvillkorstackning. 

Kommentar: Kodtackning innebar att ett eller flera 

testfall har utovat den del av koden som avses. For 
kombinationer av kodgrenvillkor innebar det 
specifikt alia kombinatoriska kombinationer (logiska) 
av villkoren samt att alia kodgrenar artackta. 


branch condition combination testing: See multiple 
condition testing. 

kombinationstestning av kodgrenar och villkor: Se 

villkorskombinationstestning. 

Kommentar: En testfallsdesignteknik dartestfallen 
designas i syfte att testa alia kombinationer av villkor 
och kodgrenval. 
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branch condition coverage: See condition coverage. 

kodgrensvillkorstackning: Se villkorstackning. 


branch coverage: The percentage of branches that have 
been exercised by a test suite. 100% branch coverage 
implies both 100% decision coverage and 100% statement 

coverage. 

bagtackning: De procentuella delarna av alia 
kodgrenar som har exekverats av en testsvit. 100% 
bagtackning omfattar bade 100% beslutsstackning 
och 100% kodsatstackning. 


branch testing: A white box test design technique in which 
test cases are designed to execute branches. 

bagtestning: En strukturell (white-box) 
testdesignteknik dartestfall utvecklasforatt 
exekvera kodgrenar. 


buffer: A device or storage area used to store data 
temporarily for differences in rates of data flow, time or 
occurrence of events, or amounts of data that can be 
handled by the devices or processes involved in the 
transferor use of the data. [IEEE 610] 

buffert: Utrustningellerett lagringsutrymme for 
tillfallig lagring av data. Lagringen sparas i form av 
skillnader i frekvens av dataflode, skillnad tid for en 
handelse eller skillnad i mangden av data som kan 
hanteras av enheten eller den process som flyttar 
eller anvander data. [IEEE 610] 


buffer overflow: A memory access failure due to the 
attempt by a process to store data beyond the boundaries 
of a fixed length buffer, resulting in overwriting of 
adjacent memory areas or the raising of an overflow 
exception. See also buffer. 

buffertoverskridande: En minnesatkomstavvikelse 

som orsakas av att en process forsoker lagra data 
utanforgranserna aven begransad buffert som 
resulterar i en overskrivning av intilliggande 
minnesareor eller en undantagshantering. Se aven 

buffert. 

F 

bug: See defect. 

bugg: Se fel. 


bug report: See defect report. 

buggrapport: Se fel rapport. 


bug taxonomy: See defect taxonomy. 

buggtaxonomi: Se defekttaxonomi. 


bug tracking tool: See defect management tool. 

bugghanteringsverktyg: Se felhanteringsverktyg. 


build verification test: A set of automated tests which 

validates the integrity of each new build and verifies its 
key/core functionality, stability and testability. It is an 
industry practice when a high frequency of build releases 
occurs (e.g., agile projects) and it is run on every new build 
before being released for further testing. 

See also smoke testing. 

verifiering av bygge: En uppsattning automatiserade 
tester som validerar integriteten hos varje nytt 
bygge och verifierar dess nyckel-/karnfunktionalitet, 
stabilitet och testabilitet. Detta ar en branschpraxis 
nar det sker tata leveranser av byggen (t.ex. i agila 
projekt) och det kors pa varje nytt bygge innan det 
slapps for vidare testning. Se aven roktest. 


burndown chart: A publicly displayed chart that depicts 
the outstanding effort versus time in a sprint (iteration). It 
shows the status and trend of completing the tasks of the 
sprint. The X-axis typically represents days in the sprint, 
while the Y-axis is effort remaining (usually either in ideal 
engineering hours or story points). 

burndown chart: Ett publikt diagram som visar den 
aterstaende insatsen kontra tiden i en sprint 
(iteration). Det visar status och trend for 
fardigstallande av uppgifterna i sprinten. X-axeln 
representerar vanligen dagarna i sprinten, medan Y- 
axeln visar aterstaende insats (vanligen antingen i 
idealarbetstimmar eller poang). 
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business process-based testing: An approach to testing in 
which test cases are designed based on descriptions 
and/or knowledge of business processes. 

verksamhetsbaserad testning: Ett angreppssatt for 
testning dartestfall tas fram baserat pa 
beskrivningar av och/eller kunskap om 
verksa mhetsprocessen. 


BVT: See build verification test. 

BVT: Build verification test. Se verifiering av bygge. 


C 



call graph: An abstract representation of calling 
relationships between subroutines in a program. 

anropsgraf: En abstrakt representation av 
anropsstrukturerna hos subrutinerna i ett program. 

ATM 

EITP 

Capability Maturity Model Integration: A framework that 
describes the key elements of an effective product 
development and maintenance process. The Capability 
Maturity Model Integration covers best-practices for 
planning, engineering and managing product development 
and maintenance. [CMMI] 

Capability Maturity Model Integration: Ett ramverk 
som beskriver de viktigaste delarna av en effektiv 
produktutvecklingoch underhallsprocess. Capability 
Maturity Model Integration tacker basta praxis for 
planering, konstruktion och hantering av 
produktutvecklingoch underhall. [CMMI] 

ATT 

capture/playback tool: A type of test execution tool 
where inputs are recorded during manual testing in order 
to generate automated test scripts that can be executed 
later (i.e. replayed). These tools are often used to support 
automated regression testing. 

in- och uppspelningsverktyg: aven skriptverktyg. 
Testverktyg dar indata spelas in under manuell 
testning for att generera automatiska testskript som 
kan exekveras senare. Dessa verktyg anvands ofta 
for att stodja automatisk regressionstestning. 

Kommentar: Ett bra sadant verktyg har aven 
mojligheter att modifiera, dvs. andra i den inspelade 

sekvensen. 


capture/replay tool: See capture/playback tool. 

in- och omspelningsverktyg: Se in- och 

uppspelningsverktyg. 


CASE: Acronym for Computer Aided Software Engineering. 

CASE: Datorstodd programutveckling. Forkortning 
fran engelska termen Computer Aided Software 
Engineering. 


CAST: Acronym for Computer Aided Software Testing. See 

also test automation. 

CAST: Datorstodd programvarutestning. Forkortning 
fran engelska Computer-Aided Software Testing Se 
aven testautomatisering. 

EITP 

causal analysis: The analysis of defects to determine their 
root cause. [CMMI] 

orsaksanalys: Analys av defekter for att identifiera 
grundorsaken till att de uppstatt. [CMMI] 


cause-effect analysis: See cause-effect graphing. 

analys baserat pa orsak-verkangrafer: Se metod for 
att skriva testfall genom orsak-verkangrafer. 

Kommentar: Analys baserat pa orsak-verkangrafer 

resulterar i beslutstabeller och som kan anvandas 

som testteknik. 
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cause-effect decision table: See decision table. 

beslutstabell for orsak-verkan relationer: Se 

beslutsta bell. 

EITP 

cause-effect diagram: A graphical representation used to 
organize and display the interrelationships of various 
possible root causes of a problem. Possible causes of a real 
or potential defect or failure are organized in categories 
and subcategories in a horizontal tree-structure, with the 
(potential) defect or failure as the root node. [After Juran] 

orsak-verkandiagram: En grafisk representation for 
att organisera och visualisera sambanden mellan 
olika potentiella grundorsakertill ett problem. 

Mojliga grundorsakertill en verkligt eller potentiell 
defekt eller avvikelse organiseras i kategorier och 
underkategorier i en horisontell tradstruktur, med 
[den potentiella] defekten eller avvikelsen som rot. 
[efter Juran] 

EITP 

cause-effect graph: A graphical representation of inputs 
and/or stimuli (causes) with their associated outputs 
(effects), which can be used to design test cases. 

orsak-verkangraf: En orsak-verkangraf ar en grafisk 
representation av indata och/eller stimuli (orsaker) 
med deras associerade utdata (effekter). Denna graf 
eller relation (ofta arrangerad i en beslutstabell) kan 
anvandas till att ska pa testfall. 

ATA 

cause-effect graphing: A black box test design technique 
in which test cases are designed from cause-effect graphs. 
[BS 7925/2] 

metod for att skriva testfall genom orsak- 
verkangrafer: En metod eller testteknik dar testfall 
skrivs genom att anvanda grafer som talar om orsak 
och verkan. [BS 7925/2] 


certification: The process of confirming that a component, 
system or person complies with its specified requirements, 
e.g. by passing an exam. 

certifiering: Processen att bekrafta att en 
komponent, ett system eller person uppfyller 
specificerade krav, t.ex. genom att klara en examen. 


change control: See configuration control. 

andringsstyrning: Se konfigurationskontroll. 


change control board: See configuration control board. 

andringsrad: Se Configuration Control Board. 

EITP 

change management: (1) A structured approach to 
transitioning individuals, and organizations from a current 
state to a desired future state. (2) Controlled way to effect 
a change, or a proposed change, to a product or service. 

See also configuration management. 

andringshantering: (1) Ett strukturerat satt att 
overfora individer och organisationerfran ett nulage 
till ett onskelage. (2) Ett kontrollerat satt att 
astadkomma en forandring, eller foreslagen 
forandring, i en produkt eller en tjanst. Se aven 
konfigurationshantering. 

ATT 

changeability: The capability of the software product to 
enable specified modifications to be implemented. [ISO 
9126] See also maintainability. 

flexibilitet: En egenskap hos programvara att tillata 
enkel implementering av specificerade andringar. 

[ISO 9126] Se aven underhallbarhet. 


charter: See test charter. 

charter: Se test charter. 


checker: See reviewer. 

kontrollant: Se granskare. 

ATA 

checklist-based testing: An experience-based test design 
technique whereby the experienced tester uses a high- 
level list of items to be noted, checked, or remembered, or 
a set of rules or criteria against which a product has to be 
verified. 

checklistebaserad testning: En erfarenhetsbaserad 
testdesignteknik i vilken en erfaren testare anvander 
en lista som innehaller punkter som ska noteras, 
kontrolleras eller kommas ihag. Listan kan aven 
innehalla regler eller kriterier mot vilka en produkt 

ska verifieras. 
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Chow's coverage metrics: See N-switch coverage. [Chow] 

tackningsmatning for Chows N-overgangar: Se 

tackning av tillstandsovergangssekvenser av langd 

N+l. 


classification tree: A tree showing equivalence partitions 
hierarchically ordered, which is used to design test cases 

in the classification tree method. See also classification 

tree method. 

klassifikationstrad: Ett strukturtrad som visar 

ekvivalensklassfordelning i hierarkisk ordning. Tradet 
anvands for att designa testfall i klassifikations-trads 
metoden. Se aven klassifikations-trads metoden. 

ATA 

classification tree method: A black box test design 
technique in which test cases, described by means of a 
classification tree, are designed to execute combinations 
of representatives of input and/or output domains. 
[Grochtmann] 

klassifikationstradsmetoden: En black-box- 
testdesignteknik i vilken testfall, beskrivna med 
utgangspunkt ur ett klassificeringstrad, ar skapade 
att utova kombinationer representativa for indata- 
och/eller utdata domaner. [Grochtmann] 


dear-box testing: See white-box testing. 

dear-box-testning: Se white-box testning. 

ATM 

EITP 

CMMI: See Capability Maturity Model Integration. 

CMMI: Se Capability Maturity Model Integration. 


code: Computer instructions and data definitions 
expressed in a programming language or in a form output 
by an assembler, compiler or other translator. [IEEE 610] 

kod: Datorinstruktioneroch datadefinitioner 

uttryckta i ett programsprak eller i ett format 
utmatat av en assembler, kompilator eller annan 
oversattare. [IEEE 610] 


code analyzer: See static code analyzer. 

kodanalysator: Se verktygforstatisk kodanalys. 

F 

code coverage: An analysis method that determines which 
parts of the software have been executed (covered) by the 
test suite and which parts have not been executed, e.g. 
statement coverage, decision coverage or condition 

coverage. 

kodtackning: En analysmetod som undersoker hur 
stor del av koden som har genomlopts med de tester 
som har utforts. Genomlopt kod mats i t.ex. 
kodsatstackning, beslutstackning eller 
villkorstackning. 


code-based testing: See white box testing. 

kodbaserad testning: Se white-box-testning. 

Kommentar: Kodbaserad testning ar en testmetod 
som syftartill att harleda testfall direktfran 
implementationen, d.v.s. programkoden, dar tester 
exekverar specifikt kontrollfldde eller anvander 
specifika data. 

EITP 

codependent behavior: Excessive emotional or 
psychological dependence on another person, specifically 
in trying to change that person's current (undesirable) 
behavior while supporting them in continuing that 
behavior. For example, in software testing, complaining 
about late delivery to test and yet enjoying the necessary 
"heroism" working additional hours to make up time when 
delivery is running late, therefore reinforcing the lateness. 

medberoende beteende: Overdrivet kanslomassigt 
eller psykologiskt beroende av en annan person, 
specifikt i situationen nar man forsdkerforandra en 
persons [oonskade] beteende samtidigt som man 
anda uppmuntrar det befintliga beteendet. T.ex., nar 
man klagar pa sena leveranser av programvara till 
testavdelningen samtidigt som man njuter av att 
spela "hjalte" genom att arbeta overtid for att ta 
igen den forlorade tiden, och pa sa satt berattigar 
forseningen. 
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ATT 

co-existence: The capability of the software product to co¬ 
exist with other independent software in a common 
environment sharing common resources. [ISO 9126] See 
also portability. 

samexisterande: Formagan hos en programvara att 
samexistera med annan oberoende programvara i en 
gemensam miljo dar dessa delar gemensamma 
resurser. [ISO 9126] Se aven portabilitet. 

ATA 

combinatorial testing: A means to identify a suitable 
subset of test combinations to achieve a predetermined 
level of coverage when testing an object with multiple 
parameters and where those parameters themselves each 
have several values, which gives rise to more 
combinations than are feasible to test in the time allowed. 

See also classification tree method, n-wise testing, 
pairwise testing, orthogonal array testing. 

kombinatorisk testning: Ett satt att identifiera en 
lamplig delmangd av testkombinationer for att 
uppna en forutbestamd niva av tackning nar man 
testar ett objekt med flera parametrar och dar dessa 
parametrar sjalva var och en har flera varden, vilket 
ger upphov till fler kombinationer an det ar mojligt 

att testa inom den foreskrivna tiden. Se aven 
klassifikationstradsmetoden, n-vis testning, parvis 
testning, testning baserad pa ortogonalitetsmatris. 

F 

Commercial Off-The-Shelsoftware: See off-the-shelf 

software. 

kommersiellt fran hyllan: Se standardprogramvara. 

Kommentar: Programvara som finns att kopa pa 
marknaden. Aven kallad tredje parts programvara. 

Kan vara ett kommersiellt verktyg, program eller 
produkt. 


comparator: See test comparator. 

jamforare: Se testkomparator. 


compatibility testing: See interoperability testing. 

kompatibilitetstestning: Se 

interoperabilitetstestning. 

Kommentar: Testning av egenskapen att systemet ar 
kompatibelt med andra system. 

Systemkompatibilitet innebar att tva eller flera 
system skall kunna samarbeta och kommunicera 
med varandra. 

F 

compiler: A software tool that translates programs 
expressed in a high order language into their machine 
language equivalents. [IEEE 610] 

kompilator: Ett program vars syfte ar att oversatta 
program fran hognivasprak till ett sprak specifikt for 
varje maskin. [IEEE 610] 


complete testing: See exhaustive testing. 

komplett testning: Se uttommande testning. 


completion criteria: See exit criteria. 

slutkriterier: Se avslutskriterier. 

F 

complexity: The degree to which a component or system 
has a design and/or internal structure that is difficult to 
understand, maintain and verify. See also cyclomatic 
complexity. 

komplexitet: Svarighetsgraden attforsta, underhalla 
eller testa ett system eller en komponents design 
eller implementation. Se aven cyklomatisk 
komplexitet. 

Kommentar: Det finns manga matvarden i olika 
verktyg, specifikt statiska analysverktyg, som pastas 
mata nagon aspekt av komplexitet. 
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compliance: The capability of the software product to 
adhere to standards, conventions or regulations in laws 
and similar prescriptions. [ISO 9126] 

typgodkannande: Kapacitet hos programvaran att 
ansluta till standarder, gangse normer eller legala 
bestammelseroch liknande foreskrifter. [ISO 9126] 


compliance testing: The process of testing to determine 
the compliance of the component or system. 

testning for typgodkannande: Den testprocess som 
bestammer att komponenten eller systemet 
uppfyllergivna regler, d.v.s. overensstammer med 
viss accepterad standard. 


component: A minimal software item that can be tested in 

isolation. 

komponent: En programvarudel som kan testas 
isoleratfran ovriga komponenter och isoleratfran 
systemet. 

Kommentar: Notera att det aven finns mer 

uttommande definitioner pa vad som exakt maste 
finnas for att kalla en programdel for komponent 
inom vissa discipliner och domaner. Grundtanken 
ligger i ateranvandbarhet av komponenter, dvs. att 
man kan anvanda en komponent pa flera stallen. 
Overgangen mellan hard- och programvara ar 
otydlig, och inom inbyggda system arordet 
komponent ocksa mycket specifikt. 


component integration testing: Testing performed to 
expose defects in the interfaces and interaction between 
integrated components. 

komponentintegrationstestning: Testning i syfte att 
hittafel i granssnitt och kommunikation mellan 
integrerade komponenter. 


component specification: A description of a component's 
function in terms of its output values for specified input 
values under specified conditions, and required non¬ 
functional behavior (e.g. resource-utilization). 

komponentspecifikation: En beskrivning av en 
komponents funktionalitet i termer av utvarden i 
forhallande till invarden vid specificerade villkor. 
Innefattar ocksa en beskrivning av kravda icke- 
funktionella egenskaper (t.ex. resursanvandning). 

F 

component testing: The testing of individual software 
components. [After IEEE 610] 

komponenttestning: Testning av individuella 
komponenter. [Efter IEEE 610] 

Kommentar: Komponenttestning ar ocksa en 
testniva i en modell, d.v.s. det som testas forst av 
utvecklare. Komponenttest ar ibland en egen 
oberoende testfas, men vanligen sker 
komponenttest parallellt med utvecklingen av 

koden. 


compound condition: Two or more single conditions 
joined by means of a logical operator (AND, OR or XOR), 
e.g. 'A>B AND C>1000'. 

multipla villkor: Tva eller fler separata villkor som ar 
sammankopplade med en logisk operator (AND, OR 
eller XOR), t.ex. "A>B AND 01000". 

ATA 

concrete test case: See low level test case. 

konkret testfall: Se testfall for lagnivatester. 
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concurrency testing: Testing to determine how the 

occurrence of two or more activities within the same 
interval of time, achieved either by interleaving the 
activities or by simultaneous execution, is handled by the 
component or system. [After IEEE 610] 

testning av samtidiga handelser: Tidsrelaterad 
testning, dar syftet ar att avgora hur 
handelseforloppet hanteras av komponenten eller 
systemet. Detta handelseforlopp bestaende avtva 
eller flera aktiviteter sker inom samma tidsintervall, 
antingen genom tidsstyrning eller nagon speciell 
ordning inom intervallet av aktiviteterna eller av 
samtidig exekvering. [After IEEE 610] 


condition: A logical expression that can be evaluated as 

True or False, e.g. A>B. See also condition testing. 

villkor: Ett logiskt uttryck som kan resultera i Sant 
eller Falskt i en utvardering, t.ex. A>B. Se aven 
villkorstestning. 


condition combination coverage: See multiple condition 

coverage. 

kombinerad villkorstackning: Se 

villkorskombinationstackning. 


condition combination testing: See multiple condition 
testing. 

testning av kombinerade villkor: Se 

villkorskombinationstestning. 


condition coverage: The percentage of condition 
outcomes that have been exercised by a test suite. 100% 
condition coverage requires each single condition in every 
decision statement to be tested as True and False. 

villkorstackning: Det procentuella utfallet av villkor 

som har exekverats av en testsvit. 100 % 
villkorstackning kraver att varje villkor i varje 
beslutspunkt maste testas som SANT och FALSKT. 


condition determination coverage: See modified 
condition decision coverage. 

tackning av villkorsbeslut: Se modifierad tackning av 

villkorsbeslut 


condition determination testing: See modified condition 
decision testing. 

testning av villkorsbeslut: Se modifierad testning av 
villkorsbeslut 


condition outcome: The evaluation of a condition to True 

or False. 

utfall av villkor: Utvardering av ett villkor, som kan 
vara antingen sant eller falskt. 

ATT 

condition testing: A white box test design technique in 
which test cases are designed to execute condition 

outcomes. 

villkorstestning: En testteknik vars syfte ar att ska pa 
testfall pa programkod, vilka exekverar villkorets 
olika mojliga utfall. 

ETM 

confidence interval: In managing project risks, the period 
of time within which a contingency action must be 
implemented in order to be effective in reducing the 
impact of the risk. 

fortroendeintervall: Den tidsperiod inom vilken en 
atgardsplan maste genomforas for att effektivt 
reducera konsekvensen av risken, vid hantering av 
projektrisker. 


confidence test: See smoke test. 

fortroendetest: Se roktest. 


configuration: The composition of a component or system 
as defined by the number, nature, and interconnections of 
its constituent parts. 

konfiguration: En sammansattning av komponenter 
eller system som definieras med numrering, karaktar 
och samhorighet med dess integrerande delar. 


configuration auditing: The function to check on the 
contents of libraries of configuration items, e.g. for 
standards compliance. [IEEE 610] 

konfigurationsrevision: aven konfigurationsaudit. 

Att kontrollera innehallet i konfigurationsobjekt, 
t.ex. uppfyllelse av standard. [IEEE 610] 
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configuration control: An element of configuration 
management, consisting of the evaluation, co-ordination, 
approval or disapproval, and implementation of changes 
to configuration items after formal establishment of their 
configuration identification. [IEEE 610] 

konfigurationsstyrning: Ett delmoment i 
konfigurationshanteringsprocessen bestaende av 
utvardering, koordinering, godkannande eller icke 
godkannande och inforande av andringar i 
konfigurationsobjekt efter det att formell 
konfigurationsidentifiering har inforts. [IEEE 610] 


configuration control board (CCB): A group of people 
responsible for evaluating and approving or disapproving 
proposed changes to configuration items, and for ensuring 
implementation of approved changes. [IEEE 610] 

CCB (Configuration Control Board): aven 
andringsrad. En grupp manniskor som ar ansvariga 
for att utvardera och godkanna eller forkasta 
foreslagna andringar av konfigurationsobjekt och for 
att sakra inforandet av godkanda andringar. [IEEE 

610] 


configuration identification: An element of configuration 
management, consisting of selecting the configuration 
items for a system and recording their functional and 
physical characteristics in technical documentation. [IEEE 
610] 

konfigurationsidentifiering: En del av 

konfigurationshanteringen som bestaravattvalja ut 
de olika konfigurationsobjekten for ett system och 
registrera deras funktionella och fysiska karaktaristik 
i teknisk dokumentation. [IEEE 610] 


configuration item: An aggregation of hardware, software 
or both, that is designated for configuration management 
and treated as a single entity in the configuration 
management process. [IEEE 610] 

konfigurationsobjekt: aven konfigurationsprodukt. 

En grupp av maskinvara, programvara eller bada, 
som ar utpekad for konfigurationshantering och 

hanteras som en enhet i 
konfigurationshanteringsprocessen. [IEEE 610] 

F 

configuration management: A discipline applying 

technical and administrative direction and surveillance to: 

identify and document the functional and physical 
characteristics of a configuration item, control changes to 
those characteristics, record and report change 15 
processing and implementation status, and verify 
compliance with specified requirements. [IEEE 610] 

konfigurationshantering (KH; KL 
(Konfigurationsledning); CM (Configuration 
Management)): Ar bade en roll och ett arbete. Som 
roll kallar man det konfigurationsledning, vars arbete 
ar att utfora konfigurationshantering. Det innebar 
beslutom uppgraderingartill nya versioner samt 
hantering av parallella versioner, dvs. att sparbarhet 
av data och program uppratthalls under modifiering. 
Disciplinen att anvanda teknisk och administrate 
styrning och overvakning. 

Kommentar: For test motsvaras detta av att man har 
kontroll over de ingaende delarna, felrattningarna 
etc. i de olika testprogramsversionerna, inklusive 
testverktygsversioner och annan testdokumentation. 

F 

configuration management tool: A tool that provides 
support for the identification and control of configuration 
items, their status over changes and versions, and the 
release of baselines consisting of configuration items. 

konfigurationshanteringsverktyg: Verktyg, dvs. 
system som underlattar identifiering och kontroll av 
konfigurationsobjekt deras status for andringar och 
versioner, och leverans avfaststalld konfiguration 
bestaende av konfigurationsobjekt. 


configuration testing: See portability testing. 

konfigurationstestning: Se portabilitetstestning. 

F 

confirmation testing: See re-testing. 

omtestning av felrattningar: Se omtestning. 
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conformance testing: See compliance testing. 

testning for overensstammelse: Se testning for 
typgodkannande. 


consistency: The degree of uniformity, standardization, 
and freedom from contradiction among the documents or 
parts of a component or system. [IEEE 610] 

overensstammelse: Grad av likformighet, 
standardisering och avsaknad av motsagelser bland 
dokument eller delar av en komponent eller ett 
system. [IEEE 610] 

ETM 

consultative testing: Testing driven by the advice and 
guidance of appropriate experts from outside the test 
team (e.g., technology experts and/or business domain 
experts). 

konsultativ testning: Testning som utfors med rad 
och vagledning fran lampliga experter utanfor 
testgruppen (t.ex. tekniska experter och/eller 
omradesexperter). 


content reference model: See content-based model. 

innehallsreferensmodell: Se innehallsbaserad 

modell. 

EITP 

content-based model: A process model providing a 
detailed description of good engineering practices, e.g. 
test practices. 

innehallsbaserad modell: En processmodell som 
innehaller detaljerade beskrivningar av god 
branschpraxis, t.ex. testpraxis. 

EITP 

continuous representation: A capability maturity model 
structure wherein capability levels provide a 
recommended order for approaching process 
improvement within specified process areas. [CMMI] 

kontinuerlig representation: En CMM (capability 
maturity model) struktur vars nivaer anger en 
rekommenderad ordningforarbetet med 
processforbattringar inom specificerat 
processomrade. 

ETM 

control chart: A statistical process control tool used to 
monitor a process and determine whether it is statistically 
controlled. It graphically depicts the average value and the 
upper and lower control limits (the highest and lowest 
values) of a process. 

kontrolldiagram: Ett statistiskt 
processtyrningsverktyg som anvands for att overvaka 
en process och avgora om det statistiskt sett ar 
under kontroll. Det visargrafiskt medelvardet och de 
ovre respektive undre kontrollgranserna (de hogsta 
och lagsta vardena) i en process. 

F 

control flow: A sequence of events (paths) in the 
execution through a component or system. 

kontrollflode: En abstrakt representation av alia 
mojliga sekvenser (vagar) i exekvering av en 
komponent eller ett system. 

ATT 

control flow analysis: A form of static analysis based on a 
representation of unique paths (sequences of events) in 
the execution through a component or system. Control 
flow analysis evaluates the integrity of control flow 
structures, looking for possible control flow anomalies 
such as closed loops or logically unreachable process 
steps. 

kontrollflodesanalys: En typ av statisk analys 
baserad pa en representation av unika vagar 
(ordnade handelser) i en exekvering av en 
komponent eller system. Kontrollflodesanalys 
utvarderar integriteten hos kontrollflddesstrukturer 
och letar specifikt efter kontrollflddesanomalier 
sasom oandliga loopar och logiskt onabara 
processteg. 


control flow graph: An abstract representation of all 
possible sequences of events (paths) in the execution 
through a component or system. 

kontrollflodesgraf: Ett diagram eller graf som 
representerar de mojliga olika kontrollfldden eller 
styrvagar som finns i programkoden. 


control flow path: See path. 

kontrollflodesvag: Se vag. 
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ATT 

control flow testing: An approach to structure-based 
testing in which test cases are designed to execute specific 
sequences of events. Various techniques exist for control 
flow testing, e.g., decision testing, condition testing, and 
path testing, that each have their specific approach and 
level of control flow coverage. See also decision testing, 
condition testing, path testing. 

kontrollflodestestning: Ett forha 1 Iningssatt till 
strukturbaserad testning dar testfall ar utformade 
for att utfora specifika sekvenser av handelser. Olika 
teknikerfinns for kontrollflodestestning, t.ex. 
beslutstestning, villkorstestning, och vagtestning, 
som var och en har sitt specifika tillvagagangssatt 
och niva pa kontrollflodestestning. Se aven 
beslutstestning, villkorstestning, vagtestning. 

ETM 

convergence metric: A metric that shows progress toward 
a defined criterion, e.g., convergence of the total number 
of test executed to the total number of tests planned for 

execution. 

konvergensmatt: Ett matetal som visar framsteg 
mot ett definierat kriterium, t.ex. konvergens av det 
totala antalet utforda tester jamfort med dettotala 
antalet planerade tester. 


conversion testing: Testing of software used to convert 
data from existing systems for use in replacement 
systems. 

konverteringstestning: Testning av program eller 
procedurer som anvands for att konvertera data fran 
ett befintligt system till ett annat nytt eller 
ersattande system. 

EITP 

corporate dashboard: A dashboard-style representation of 
the status of corporate performance data. See also 
balanced scorecard, dashboard. 

corporate dashboard: En presentation avforetagets 
status med hjalp av ett instrumentpanelliknande 
verktyg. Se aven balanserat styrkort, styrkort och 

dashboard. 


cost of quality: The total costs incurred on quality 
activities and issues and often split into prevention costs, 
appraisal costs, internal failure costs and external failure 

costs. 

kvalitetskostnad: Den totala kostnaden som resultat 

av kvalitetsarbete och kvalitetsproblem ofta 
uppdelat i forbyggande, analys-, interna 
felsymptoms- och externa felsymptomskostnader. 

F 

COTS: Acronym for Commercial Off-The-Shelf software. 

See off-the-shelf software. 

COTS: Forkortning fran engelska namnet Commercial 
Off-The-Shelf software. Se aven kommersiellt fran 

hyllan. 


coverage: The degree, expressed as a percentage, to 
which a specified coverage item has been exercised by a 

test suite. 

tackningsgrad: Den niva, uttryckt i procent, till vilket 
ett specificerat objekt har blivit exekverat av en 

testsvit. 


coverage analysis: Measurement of achieved coverage to 
a specified coverage item during test execution referring 
to predetermined criteria to determine whether additional 
testing is required and if so, which test cases are needed. 

tackningsanalys: Analys av den matniva, 
procentuellt uttryckt, till vilket ett specificerat objekt 

har blivit tackt av en testsvit. Ofta avses att man 
uppfyller en pa forhand given testniva, dar flera 

testfall kan behovas for att na den. 


coverage item: An entity or property used as a basis for 
test coverage, e.g. equivalence partitions or code 

statements. 

tackningsobjekt: Den del man mater tackning pa, 

t.ex. ekvivalensklasser eller kodrader. 


coverage measurement tool: See coverage tool. 

verktyg for att mata tackningsgrad: Se verktyg for 
test av tackningsgrad. 
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F 

coverage tool: A tool that provides objective measures of 
what structural elements, e.g. statements, branches have 
been exercised by a test suite. 

verktyg for test av tackningsgrad: Ett verktyg som 
visar hur strukturella element, t.ex. kodsatser och 
kodgrenar, har exekverats av en testsvit. 

EITP 

critical success factor: An element necessary for an 
organization or project to achieve its mission. Critical 
success factors are the critical factors or activities required 
for ensuring the success. 

kritisk framgangsfaktor: Nodvandiga komponenter 
for att en organisation eller ett foretag med 
framgang ska kunna uppna sina mal kallas for kritiska 
framgangsfaktorer. Se aven innehallsbaserad modell. 

ATM 

EITP 

Critical Testing Processes: A content-based model for test 
process improvement built around twelve critical 
processes. These include highly visible processes, by which 
peers and management judge competence and mission- 
critical processes in which performance affects the 
company's profits and reputation. See also content-based 
model. 

Critical Testing Processes: En innehallsbaserad 
modell fortestprocessforbattring som bygger pa tolv 
tydliga delprocesser. Bland dessa ingarde mest 
kritiska processerna for foretagets vinst och rykte 
och anvands av ledning och medarbetare for att 
bedoma foretagets kompetens och prestanda. Se 
aven innehallsbaserad modell. 

ATM 

EITP 

CTP: See Critical Testing Processes. 

CTP: Se Critical Testing Processes. 


custom software: See bespoke software. 

anpassad programvara: Se kundanpassad 

programvara. 

ATM 

custom tool: A software tool developed specifically for a 

set of users or customers. 

anpassat verktyg: Ett program verktyg utvecklat 
speciellt for en grupp anvandare eller kunder. 

ATT 

cydomatic complexity: The maximum number of linear, 
independent paths through a 

program. Cyclomatic complexity may be computed as: L - 
N + 2P, where 

- L = the number of edges/links in a graph 

- N = the number of nodes in a graph 

- P = the number of disconnected parts of the graph (e.g. a 
called graph or subroutine) 

[After McCabe] 

cyklomatisk komplexitet: Dettotala antalet 
oberoende exekveringsvagar genom ett program. 
Cyklomatisk komplexitet definieras som: L - N + 2P, 
dar L = antalet bagar i en graf, N = antalet noder i en 
graf och P = antalet separerade delar i en graf (t.ex. 
en anropad graf och en subrutin). [Efter McCabe] 


cyclomatic number: See cyclomatic complexity. 

cyklomatiskt matt: Se cyklomatisk komplexitet. 


D 



daily build: A development activity whereby a complete 
system is compiled and linked every day (often overnight), 
so that a consistent system is available at any time 
including all latest changes. 

dagligt bygge: En utvecklingsaktivitet dar ett 
komplett system kompileras och lankas varje dag 
(oftast nattetid). Ett dagligt bygge mojliggdrtillgang 
till ett konsekvent system dar alia de senaste 
andringarna ingar. 
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ETM 

dashboard: A representation of dynamic measurements of 
operational performance for some organization or activity, 
using metrics represented via metaphores such as visual 
'dials', 'counters', and other devices resembling those on 
the dashboard of an automobile, so that the effects of 
events or activities can be easily understood and related 
to operational goals. See also corporate dashboard, 

scorecard. 

dashboard: En representation av dynamiska 
matningar av operativ prestanda for en 
organisations aktiviteter, via matetal representerade 
av metaforer som t.ex. "visare", "raknare" och 
"indikatorer" liknande de som kan ses pa 
instrumentbradan hos en bil. Detta goratt 
effekterna av handelser och aktiviteter enkelt kan 

forstas och relateras till operativa mil. Se aven 
corporate dashboard, styrkort och balanserat 
styrkort. 


data definition: An executable statement where a variable 

is assigned a value. 

datadefinition: En exekverbarsats dar en variabel 

tilldelas ett varde. 

F 

data flow: An abstract representation of the 
sequence and possible changes of the state of 
data objects, where the state of an object is any 
of: creation, usage, or destruction. [Beizer] 

dataflode: En abstrakt representation av en sekvens 
och mojliga forandringar av tillstandet hos ett 
dataobjekt dar tillstandet ar ett av foljande: ska pa 
(eng. creation), anvanda (eng. usage) eller 
destruktion (eng. destruction). [Beizer] 

ATT 

data flow analysis: A form of static analysis based on the 
definition and usage of variables. 

dataflodesanalys: En form av statisk analys som 
grundar sig pa tilldelning och anvandning av 

variabler. 


data flow coverage: The percentage of definition-use pairs 
that have been exercised by a test suite. 

dataflodestackning: Den procentuella andel av alia 
definitions- och anvandningspar som har exekverats i 

en testsvit. 


data flow testing: A white box test design technique in 
which test cases are designed to execute definition-use 
pairs of variables. 

testning av dataflode: En testdesign teknik dar 
testfallen ar designade for att utova definitions- och 
anvandningspar av variabler. 


data integrity testing: See database integrity testing. 

testning av dataintegritet: Se testning av 
databasintegritet. 


database integrity testing: Testing the methods and 
processes used to access and manage the data(base), to 
ensure access methods, processes and data rules function 
as expected and that during access to the database, data is 
not corrupted or unexpectedly deleted, updated or 

created. 

testning av databasintegritet: Testning av metoder 
och processer som anvands for atkomst och 
hantering av data(baser), for att sakerstalla att 
atkomstmetoder, processer och datareglerfungerar 
som vantat. Vid atkomst av databas ska ocksa test 

utforas for att sakerstalla att data inte forstdrs och 

att data inte ovantat raderas, uppdateras eller 
skapas. 
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F 

ATT 

data-driven testing: A scripting technique that stores test 
input and expected results in a table or spreadsheet, so 
that a single control script can execute all of the tests in 
the table. Data-driven testing is often used to support the 
application of test execution tools such as 
capture/playback tools. [Fewster and Graham] See also 
keyword-driven testing. 

datadriven testning: En testteknik dar testdata, dvs. 
invarden till testning, separeras fran testfall. Ett 
vanligt tillvagagangssatt ar att lagga de separerade 
invardena i en tabell eller ett kalkylblad, och sedan 
lata mer generellt skrivna testfall lasa och anvanda 
dem. Datadriven testning anvands ofta for att stodja 
anvandning av testexekveringsverktyg t.ex. in- och 
uppspelningsverktyg. [Fewster and Graham] Se aven 
nyckelordsdriven testning. 


dd-path: A path between two decisions of an algorithm, or 
two decision nodes of a corresponding graph, that 
includes no other decisions. See also path. 

dd-path: En vag mellan tva beslutspunkter i en 
algoritm, eller tva beslutsnoder i en motsvarande 
graf, som inte innehaller nagra andra beslut. Se aven 

vag. 


dead code: See unreachable code. 

dod kod: Se onabar kod. 


debugger: See debugging tool. 

avlusare: aven debugger. Se avlusningsverktyg. 

F 

debugging: The process of finding, analyzing and removing 

the causes of failures in software. 

avlusning: aven debuggning. Processen att hitta, 
analysera och avlagsna orsaker till felsymptom i 

programvara. 

F 

ATT 

debugging tool: A tool used by programmers to reproduce 
failures, investigate the state of programs and find the 
corresponding defect. Debuggers enable programmers to 
execute programs step by step, to halt a program at any 
program statement and to set and examine program 
variables. 

avlusningsverktyg: aven debuggningsverktyg. Ett 
verktyg som anvands av programmerare for att 
aterskapa felsymptom och undersoka program i 
syfte att hitta var det finns fel som orsakar 
felsymptom. Dessa verktyg gor det mojligtfdr 
utvecklare att undersoka program rad for rad, att 
stanna pa en viss kodrad i programmet och att 
undersoka programvariabler. 


decision: A program point at which the control flow has 

two or more alternative routes. A node with two or more 

links to separate branches. 

kodvillkor: En punkt i programmet dar kodvillkoret 
ledertill att en avtva eller flera mojliga vagar valjs. 


decision condition coverage: The percentage of all 

condition outcomes and decision outcomes that have 

been exercised by a test suite. 100% decision condition 
coverage implies both 100% condition coverage and 100% 
decision coverage. 

kodvillkor/villkorstackning: Den procentuella andel 
av alia utfall fran villkor och utfall fran kodvillkor som 

har exekverats i en testsvit. 100 % 
kodvillkor/villkorstackning inbegriper bade 100 % 
villkorstackning och 100 % beslutstackning. 

ATT 

decision condition testing: A white box test design 
technique in which test cases are designed to execute 

condition outcomes and decision outcomes. 

beslut-/villkorstestning: En white-box- 
testdesignteknik dar testfall ar utvecklade for att 
exekvera utfall fran villkor och utfall fran kodvillkor. 

F 

decision coverage: The percentage of decision outcomes 
that have been exercised by a test suite. 100% decision 
coverage implies both 100% branch coverage and 100% 
statement coverage. 

beslutstackning: Den procentuella del av kodvillkor 

som har exekverats av en testsvit. 100 % 
beslutstackning innebar bade 100 % bagtackning och 
100 % kodsatstackning. 
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decision outcome: The result of a decision (which 
therefore determines the branches to be taken). 

utfallet fran ett kodvillkor: Resultatet av ett beslut, 
som avgor vilket specifikt kontrollfldde, dvs. vilken 
kodgren som kommer att exekveras. 


decision table: A table showing combinations of inputs 
and/or stimuli (causes) with their associated outputs 
and/or actions (effects), which can be used to design test 

cases. 

beslutstabell: En tabell som visar invarden och/eller 
stimuli med motsvarande utvarden och/eller 
funktion (verkan). Anvands for att ta fram testfall. 

F 

ATA 

decision table testing: A black box test design technique in 
which test cases are designed to execute the combinations 
of inputs and/or stimuli (causes) shown in a decision table. 
[Veenendaal04] See also decision table. 

testning med hjalp av beslutstabeller: Testning med 
hjalp aven beslutstabell, vilken sammanfattar villkor 

och dess resulterande handelser eller beslut. Se aven 

beslutsta bell. 


decision testing: A white box test design technique in 
which test cases are designed to execute decision 

outcomes. 

beslutstestning: En white-box-testdesignteknik dar 
testfall tas fram for att exekvera beslutsvagar i 
programkoden. 

F 

ATM 

defect: A flaw in a component or system that can cause 
the component or system to fail to perform its required 
function, e.g. an incorrect statement or data definition. A 
defect, if encountered during execution, may cause a 
failure of the component or system. 

defekt: Se fel. 


defect category: See defect type. 

defektkategori: Se defekttyp. 

F 

defect density: The number of defects identified in a 
component or system divided by the size of the 
component or system (expressed in standard 
measurement terms, e.g. lines-ofcode, number of classes 
or function points). 

defekttathet: Antal fel funna i en komponent eller 
ett system dividerat med storleken pa komponenten 
eller systemet (uttryckt i standardmattermer, t.ex. 
kodrader, antal klasser eller funktionsenheter). 

EITP 

Defect Detection Percentage (DDP): The number of 
defects found by a test phase, divided by the number 
found by that test phase and any other means afterwards. 

Defect Detection Percentage (DDP): Antaletfel 

funna i en testfas dividerat med summan av dessa fel 

och fel funna i senare testfaser eller under andra 

situationer, t.ex. drift. 


defect management: The process of recognizing, 
investigating, taking action and disposing of defects. It 
involves recording defects, classifying them and identifying 
the impact. [After IEEE 1044] 

felhantering: Processen att identifiera, utreda och 
vidta atgarder samt avfora fel. Den omfattar 
registrering och klassificera avfel samtfaststallande 
av deras paverkan. [Efter IEEE 1044] 

ATM 

defect management committee: A cross-functional team 
of stakeholders who manage reported defects from initial 
detection to ultimate resolution (defect removal, defect 
deferral, or report cancellation). In some cases, the same 
team as the configuration control board. See also 
configuration control board. 

felhanteringsrad: En tvarfunktionell grupp 
intressenter som hanterar rapporterade fel fran 
forsta upptackt till slutliga losning (avlagsning, 
uppskjutning eller annullering). 1 vissa fall samma 
grupp som CCB. Se aven CCB (Configuration Control 
Board). 
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defect management tool: A tool that facilitates the 
recording and status tracking of defects and changes. They 

often have workflow-oriented facilities to track and 

control the allocation, correction and re-testing of defects 
and provide reporting facilities. See also incident 
management tool. 

felhanteringsverktyg: Ett verktyg som underlattar 
registrering och tillstandssparning av fel. 1 
felhanteringsverktyg finns ofta stod for attfolja ett 
arbetsflode och for styrning, tilldelning, atgard och 
omtestning av handelser eller fel, och det 
tillhandahaller hjalp for rapportering. 


defect masking: An occurrence in which one defect 
prevents the detection of another. [After IEEE 610] 

defektmaskering: Se felmaskering. 


defect report: A document reporting on any flaw in a 
component or system that can cause the component or 
system to fail to perform its required function. [After IEEE 
829] 

felrapport: Ett dokument som rapporterar en brist i 
en komponent eller ett system. Bristen kan medfora 
att komponenten eller systemet misslyckas med att 
utfora en onskad funktionalitet. [Efter IEEE 829] 

ATA 

defect taxonomy: A system of (hierarchical) categories 
designed to be a useful aid for reproducibly classifying 

defects. 

defekttaxonomi: Ett system av (hierarkiskt ordnade) 
kategorier designade att vara anvandbara i arbetet 
med att (reproducerbart) klassificera defekter. 


defect tracking tool: See defect management tool. 

felsparningsverktyg: Se felhanteringsverktyg. 

ATM 

defect triage committee: See defect management 

committee. 

felprioriteringsrad: se felhanteringsrad 


defect type: An element in a taxonomy of defects. Defect 
taxonomies can be identified with 

respect to a variety of considerations, including, but not 

limited to: 

• Phase or development activity in which the defect is 
created, e.g., a specification error 

or a coding error 

• Characterization of defects, e.g., an "off-by-one" defect 

• Incorrectness, e.g., an incorrect relational operator, a 
programming language syntax 

error, or an invalid assumption 

• Performance issues, e.g., excessive execution time, 
insufficient availability. 

feltyp: En enhet i en defekttaxonomi (aven 
defektklassificering). Defekttaxonomier kan 

identifieras med 

avseende pa en mangd olika overvaganden, 
inbegripet, men inte begransat till: 

• Fas eller utvecklingsaktivitet dar felet ska pas, t.ex. 
fel i specifikationen eller fel i koden 

• Karaktarisering av defekter, t.ex. ett gransvardesfel 

• Inkorrekthet, t.ex. en felaktig relationsoperator, ett 
syntaxfel for aktuellt programsprak eller ett ogiltigt 
antagande 

• Prestandaproblem, t.ex. overdriven exekveringstid, 
otillracklig tillganglighet. 

ATA 

defect-based technique: See defect-based test design 
technique. 

defektbaserad teknik: Se defektbaserad 
testdesignteknik. 

ATA 

defect-based test design technique: A procedure to derive 
and/or select test cases targeted at one or more defect 
types, with tests being developed from what is known 
about the specific defect type. 

See also defect taxonomy. 

defektbaserad testdesignteknik: En procedurforatt 
basera och/eller valja testfall for en eller flera 
defekttyper, dar test utvecklas utifran vad som ar 
kant for en specifik defekttyp. Se aven 
defekttaxonomi. 

ATT 

definition-use pair: The association of a definition of a 
variable with the subsequent use of that variable. Variable 
uses include computational (e.g. multiplication) or to 
direct the execution of a path ("predicate" use). 

definitions- och anvandningspar: Relationen mellan 
en definition och en anvandning av en variabel. 
Anvandning av en variabel ingar antingen i en 
berakning eller i ett villkor. 
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deliverable: Any (work) product that must be delivered to 
someone other than the (work) product's author. 

leverabel: En produkt som formellt skall overlamnas 
till en utpekad mottagare. 

EITP 

Deming cycle: An iterative four-step problem-solving 
process, (plan-do-check-act), typically used in process 
improvement. [After Deming] 

Deming-cykel: En iterativ problemlosningsprocess i 
fyra steg (planera-utfora-kontrollera-agera) som ofta 
anvands vid processforbattring. [efter Deming] 


design-based testing: An approach to testing in which test 
cases are designed based on the architecture and/or 
detailed design of a component or system (e.g. tests of 
interfaces between components or systems). 

designbaserad testning: Ett angreppssatt for 
testning dar utvecklingen av testfall baseras pa 
arkitekturen och/eller detaljerad design av 
komponenten ellersystemet (t.ex. granssnitt mellan 
komponenter eller system). 


desk checking: Testing of software or a specification by 
manual simulation of its execution. See also static testing. 

skrivbordstest: Testning av programvara eller 
specifikation genom manuell simulering av en 
exekvering. Se aven statisk testning. 


development testing: Formal or informal testing 
conducted during the implementation of a component or 
system, usually in the development environment by 
developers. [After IEEE 610] 

utvecklingstestning: Formell eller informell testning 
som utfors under utvecklingen av en komponent 
eller ett system. Utfors oftast i utvecklingsmiljon av 
utvecklarna sjalva. [Efter IEEE 610] 


deviation: See incident. 

avvikelse: Flandelser som sker vid testning och som 
kraver vidare utredning. [Efter IEEE 1008] 


deviation report: See incident report. 

avvikelserapport: Se eng. "incident report". 

EITP 

diagnosing (IDEAL): The phase within the IDEAL model 
where it is determined where one 

is, relative to where one wants to be. The diagnosing 
phase consists of the activities: 
characterize current and desired states and develop 
recommendations. See also IDEAL. 

diagnostisering (IDEAL): Den fas inom IDEAL 
modellen i vilken man faststaller var man ar i 

forhallande till var man vill vara. 

Diagnostiseringsfasen bestar av aktiviteterna: 
karakterisera nuvarande och onskade tillstand samt 

utveckla rekommendationer. Se aven IDEAL. 


dirty testing: See negative testing. 

destruktiv testning: Se negativ testning. 


documentation testing: Testing the quality of the 
documentation, e.g. user guide or installation guide. 

testning av dokument: Testning av kvaliteten pa 
dokument, t.ex. anvandarmanualer och 

installationsinstruktioner. 


domain: The set from which valid input and/or output 

values can be selected. 

doman: Den uppsattning data fran vilken giltiga in- 
och/ellerutdata kan valjas. Doman betyderocksa 
omrade/gebit, t.ex. inom bank, finans, inbyggda 
system. 

ATA 

domain analysis: A black box test design technique that is 
used to identify efficient and effective test cases when 
multiple variables can or should be tested together. It 
builds on and generalizes equivalence partitioning and 
boundary values analysis. See also boundary value 
analysis, equivalence partitioning. 

domananalys: En black-box-testdesignteknik som 
anvands for att identifiera andamalsenliga och 
effektiva testfall nar flera variabler kan eller bor 

provastillsammans. Den bygger pa och generaliserar 
ekvivalensklassindelning och gransvardesanalys. Se 
aven ekvivalensklassindelning, gransvardesanalys. 
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F 

driver: A software component or test tool that replaces a 
component that takes care of the control and/or the 
calling of a component or system. [After TMap] 

drivrutin: aven driver. En programvarukomponent 
eller ett testverktyg som ersatter en komponent och 
tar kontroll och/eller anrop till en komponent eller 
system. [EfterTMap] 

ATT 

dynamic analysis: The process of evaluating behavior, e.g. 
memory performance, CPU usage, of a system or 
component during execution. [After IEEE 610] 

dynamisk analys: Processen att utvardera ett system 
eller en komponent baserat pa dess beteende under 
exekvering.[Efter IEEE 610] Motsats: statisk analys. 

F 

dynamic analysis tool: A tool that provides run-time 

information on the state of the software code. These tools 

are most commonly used to identify unassigned pointers, 
check pointer arithmetic and to monitor the allocation, 
use and de-allocation of memory and to flag memory 

leaks. 

dynamiskt analysverktyg: Ett verktyg som 
tillhandahaller realtidsinformation om tillstandet for 

programvaran. Dessa verktyg anvands oftast for att 
identifiera ej tilldelade pekare, visa minnesallokering 
och flagga for minneslackor. 


dynamic comparison: Comparison of actual and expected 
results, performed while the software is being executed, 
for example by a test execution tool. 

dynamisk jamforelse: Jamforelse av aktuellt och 
forvantat resultat som gors medan programmet 
exekveras, t.ex. med hjalp av ett 
testexekveringsverktyg. 

F 

dynamic testing: Testing that involves the execution of the 
software of a component or system. 

dynamisk testning: Testning som innefattar 
exekvering av programvaran till en komponent eller 
ett system. 


E 


ATM 

effectiveness: The capability of producing an intended 
result. See also efficiency. 

andamalsenlighet: Formagan att producera avsett 

resultat. Se aven effektivitet. 

ATM 

ATT 

efficiency: (1) The capability of the software product to 
provide appropriate performance, relative to the amount 
of resources used understated conditions. [ISO 9126] (2) 
The capability of a process to produce the intended 
outcome, relative to the amount of resources used. 

effektivitet: (1) Programvarans formaga att 
tillhandahalla tillrackliga prestanda i relation till 
anvanda resurser och under definierade villkor. [ISO 
9126] (2) Formagan hos en process att producera 
avsett resultat, i forhallande till den mangd resurser 

som anvands. 


efficiency testing: The process of testing to determine the 
efficiency of a software product. 

effektivitetstestning: Testning som utfors for att 
avgora hurtidseffektiv en programvaruprodukt ar. 

EITP 

EFQM (European Foundation for Quality Management) 
excellence model: A nonprescriptive framework for an 
organisation's quality management system, defined and 
owned by the European Foundation for Quality 
Management, based on five 'Enabling' criteria (covering 
what an organisation does), and four 'Results' criteria 
(covering what an organisation achieves). 

EFQM (European Foundation for Quality 
Management) excellensmodell: Ett icke-normativt 
ramverk for en organisations 
kvalitetsledningssystem, framtaget och agt av 
European Foundation for Quality Management, 
baserat pa fern "aktiveringskriterier" (vilka tacker 
vad organisationen gor) och fyra "resultatkriterier" 
(vilka tacker vad organisationen uppnar). 
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elementary comparison testing: A black box test design 
technique in which test cases are designed to execute 
combinations of inputs using the concept of modified 
condition decision coverage. [TMap] 

grundlaggande jamforelsetestning: En black-box- 
designteknik dar testfallen ar utvecklade for att 
exekvera en kombination av indata enligt begreppet 
MCDCtackning. [TMap] 


embedded iterative development model: A development 
lifecycle sub-model that applies an iterative approach to 
detailed design, coding and testing within an overall 
sequential model. In this case, the high level design 
documents are prepared and approved for the entire 
project but the actual detailed design, code development 
and testing are conducted in iterations. 

inbaddad iterativ utvecklingsmodell: En 

underliggande livscykelmodell vid utveckling som 
tillampar en iterativ metod for detaljerad design, 
kodning och testning inom en overgripande 
sekventiell modell. 1 detta fall ar designdokument pa 
hog niva utarbetade och godkanda for hela projektet 
men detaljerad design, kodning och testning sker i 

iterationer. 

EITP 

emotional intelligence: The ability, capacity, and skill to 
identify, assess, and manage the emotions of one's self, of 
others, and of groups. 

emotionell intelligens (EQ): Formaga eller skicklighet 
att identifiera och hantera sinnesstamningar hos sig 
sjalv, hos andra individer och hos grupper. 


emulator: A device, computer program, or system that 
accepts the same inputs and produces the same outputs 
as a given system. [IEEE 610] See also simulator. 

emulator: Utrustning, program eller system som 
accepterarsamma indata och producerarsamma 
utdata som ett bestamt system. [IEEE 610] Se aven 
simulator. 

F 

entry criteria: The set of generic and specific conditions 
for permitting a process to go forward with a defined task, 
e.g. test phase. The purpose of entry criteria is to prevent 
a task from starting which would entail more (wasted) 
effort compared to the effort needed to remove the failed 
entry criteria. [Gilb and Graham] 

startkriterier: Den mangd av generiska och specifika 
villkor som tillater en process att fortsatta med ett 
definierat arbete, t.ex. en testfas. Syftet med 

startkriterier ar att forhindra start av ett arbete som 
annars skulle medfora mer (onodig) insats jamfort 
med insatsen att eliminera de felaktiga 
startkriterierna. [Gilb and Graham] 


entry point: An executable statement or process step 
which defines a point at which a given process is intended 
to begin. 

exekveringsstartpunkt: En exekverbar kodsats eller 
processteg som utgor startpunkt for en given 

process. 


equivalence class: See equivalence partition. 

ekvivalensklass: Se ekvivalensuppdelning. 


equivalence partition: A portion of an input or output 
domain for which the behavior of a component or system 
is assumed to be the same, based on the specification. 

ekvivalensuppdelning: aven ekvivalensindelning. Ett 
omrade i en in- eller utmatning dar ett testobjekt 
kan antas ha samma beteende inom omradet, dar 
antagandet kan vara baserat pa en specifikation eller 
vara underforstatt av sammanhanget. 


equivalence partition coverage: The percentage of 
equivalence partitions that have been exercised by a test 

suite. 

ekvivalensklasstackning: Den procentuella delen av 

alia ekvivalensklasser som har blivit tackta av en 

testsvit. 
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F 

ATA 

equivalence partitioning: A black box test design 
technique in which test cases are designed to execute 
representatives from equivalence partitions. In principle 
test cases are designed to cover each partition at least 

ekvivalensklassindelning: En black-box- 
testdesignteknik dar testfall har utvecklats for att 
exekvera representativa varden i ekvivalensklasser. 1 
princip tas testfall fram for att tacka varje 
ekvivalensklass atminstone en gang. 

F 

error: A human action that produces an incorrect result. 
[After IEEE 610] 

misstag: (1) En mansklig atgard som producerar ett 
felaktigt resultat. [Efter IEEE 610] Se aven manskligt 
misstag. 

(2) aven felaktighet. Se fel. 

F 

ATA 

error guessing: A test design technique where the 
experience of the tester is used to anticipate what defects 
might be present in the component or system under test 
as a result of errors made, and to design tests specifically 
to expose them. 

felgissning: En testdesignteknik dartestarens 

erfarenhet anvands for att forutse vilka fel som kan 

finnas i den komponent eller det system som testas. 
Tekniken bygger pa tidigare fel och anvands for att 

utveckla testfall som visardessa eventuella fel. 


error seeding: See fault seeding. 

injektion av felaktighet: Se felinjektion. 


error seeding tool: See fault seeding tool. 

verktyg for injektion av felaktighet: Se 

felinjektionsverktyg. 


error tolerance: The ability of a system or component to 
continue normal operation despite the presence of 
erroneous inputs. [After IEEE 610]. 

tolerans mot felaktighet: Se feltolerans. 


escaped defect: A defect that was not detected in a 
previous test level which is supposed to find such defects. 
See also Defect Detection Percentage. 

missatfel: Ett fel som inte upptacktes pa en tidigare 

testniva dar sadana fel forvantas hittas. Se aven 

Defect Detection Percentage (DDP). 

EITP 

establishing (IDEAL): The phase within the IDEAL model 
where the specifics of how an 

organization will reach its destination are planned. The 

establishing phase consists of the 

activities: set priorities, develop approach and plan 

actions. See also IDEAL. 

etablering (IDEAL): Den fas inom IDEAL modellen i 
vilken man planerar detaljerna for hur en 
organisation ska kunna na sina mal. Etableringsfasen 
bestarav aktiviteterna: prioritera, utveckla 
tillvagagangssatt och planera atgarder. Se aven 

IDEAL. 


evaluation: See testing. 

utvardering: Se testning. 


exception handling: Behavior of a component or system in 
response to erroneous input, from either a human user or 
from another component or system, or to an internal 

failure. 

undantagshantering: Beteendet hos en komponent 
eller ett system som blivit utsatt for felaktigt invarde, 
antingen inmatat av en anvandare eller fran en 
annan komponent eller system, eller p.g.a. ett 
interntfel. 


executable statement: A statement which, when 
compiled, is translated into object code, and which will be 
executed procedurally when the program is running and 
may perform an action on data. 

exekverbar sats: En sats som nar den kompileras 
oversatts till objektkod som kan utfora handelser, 
hantera data eller utfora en berakning. En 

exekverbar sats kommer att exekveras 
procedurmassigt nar programmet exekveras. 
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exercised: A program element is said to be exercised by a 
test case when the input value causes the execution of 
that element, such as a statement, decision, or other 

structural element. 

utovad: aven kord, motionerad. En programdel 
utovas/motioneras av ett testfall nar ett invarde 
medfor en exekvering av programdelen, sasom sats, 
villkor eller andra strukturella konstruktioner. 

F 

exhaustive testing: A test approach in which the test suite 
comprises all combinations of input values and 
preconditions. 

uttommande testning: aven fullstandig testning. Ett 
angreppssatt dartestsviten bestarav alia 
kombinationer av indata och forutsattningar. 

F 

ATM 

ATA 

exit criteria: The set of generic and specific conditions, 
agreed upon with the stakeholders for permitting a 
process to be officially completed. The purpose of exit 
criteria is to prevent a task from being considered 
completed when there are still outstanding parts of the 

task which have not been finished. Exit criteria are used to 
report against and to plan when to stop testing. [After Gilb 
and Graham] 

avslutskriterier: En uppsattning generiska och 
specifika villkor som har overenskommits med 
intressenter och som maste vara uppfyllda for att en 
process officiellt ska anses vara klar. Syftet med 
avslutskriterier ar att forhindra att ett arbete anses 

avslutat nar det fortfarande finns delar som inte ar 

avslutade. Avslutskriterier anvands inom test for att 

planera och rapportera nartestningen skall avslutas. 
[Efter Gilb and Graham] 


exit point: An executable statement or process step which 
defines a point at which a given process is intended to 

cease.. 

avslutspunkt: En exekverbar kodsats eller processteg 
som utgdrslutpunktforen given process. 


expected outcome: See expected result. 

forvantat utfall: Se forvantat resultat. 


expected result: The behavior predicted by the 
specification, or another source, of the component or 
system underspecified conditions. 

forvantat resultat: Predikterat beteende hos en 

komponent eller ett system under specificerade 
villkor som forutsagts i en specifikation eller annan 

kalla. 

ATA 

experience-based technique: See experience-based test 
design technique. 

erfarenhetsbaserad teknik: Se erfarenhetsbaserad 

testdesignteknik. 

F 

ATA 

experience-based test design technique: Procedure to 
derive and/or select test cases based on the tester's 
experience, knowledge and intuition. 

erfarenhetsbaserad testdesignteknik: En 

testdesignteknik dar man inte foljer nagon speciell 
testdesignteknik, utan anvander sin samlade 
kunskap. Se aven felgissning. 


experience-based testing: Testing based on the tester's 
experience, knowledge and intuition. 

erfarenhetsbaserad testning: Testning baserad pa 
testarens erfarenhet, kunskap och intuition. 

F 

ATA 

exploratory testing: An informal test design technique 
where the tester actively controls the design of the tests 
as those tests are performed and uses information gained 
while testing to design new and better tests. [After Bach] 

utforskande testning: aven upptackande testning. 

En informell testdesignteknik dar testaren aktivt styr 
utveckling av testfall under det att de exekveras och 
anvander information fran testningen for att 
utveckla nya och battre testfall. [Efter Bach] 
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EITP 

extreme programming (XP): A software engineering 
methodology used within agile software development 
whereby core practices are programming in pairs, doing 
extensive code review, unit testing of all code, and 
simplicity and clarity in code. See also agile software 
development. 

extreme programming (XP): En 

programvaruutvecklingsmetodik, som anvands inom 
agil programvaruutveckling, i vilken de centrala 
aktiviteterna innefattar parprogrammering, 
omfattande kodgranskning, enhetstestning av all kod 
samt enkel och tydlig kodning. Se aven agil 
programvaruutveckling. 


F 



factory acceptance testing: Acceptance testing conducted 
at the site at which the product is developed and 
performed by employees of the supplier organization, to 
determine whether or not a component or system satisfies 
the requirements, normally including hardware as well as 
software. See also alfa testing. 

fabriksacceptanstestning: Acceptanstestning 
genomfors vid den plats dar produkten utvecklas och 
utfors av anstallda inom leverantorens organisation, 
for att avgora om en komponent eller ett system 
uppfyller kraven, normalt inklusive hardvara samt 
mjukvara. Se aven alfatestning. 


fail: A test is deemed to fail if its actual result does not 

match its expected result. 

underkand: En test anses underkand om dess 

faktiska resultat inte stammer motforvantat 

resultat. 


failover testing: Testing by simulating failure modes or 
actually causing failures in a controlled environment. 
Following a failure, the failover mechanism is tested to 
ensure that data is not lost or corrupted and that any 
agreed service levels are maintained (e.g., function 
availability or response times). See also recoverability 
testing. 

failover testning: Testning genom att simulera 
fellagen eller faktiskt orsaka fel i en kontrollerad 
miljo. Efter ett misslyckande testas 

failovermekanismen for att sakerstalla att data inte 

forloras eller forvanskas och att alia overenskomna 

servicenivaer uppratthalls (t.ex. 
funktionstillganglighet eller svarstider). Se aven 
aterhamtningsbarhetstestning. 

F 

ATM 

failure: Deviation of the component or system from its 
expected delivery, service or result. [After Fenton] 

felsymptom: aven felyttring. Avvikelse fran 
programvarans eller systemets forvantade beteende 
eller resultat. [Efter Fenton] 


failure mode: The physical or functional manifestation of a 
failure. For example, a system in failure mode may be 
characterized by slow operation, incorrect outputs, or 
complete termination of execution. [IEEE 610] 

feltillstand: Den fysiska eller funktionella yttringen 
av ett felsymptom. Ett system i felsymptomslage kan 
t.ex. ge tecken pa langsam funktion, felaktiga 
utvarden eller exekveringsavbrott. [IEEE 610] 

EITP 

Failure Mode and Effect Analysis (FMEA): A systematic 
approach to risk identification and analysis of identifying 
possible modes of failure and attempting to prevent their 
occurrence. See also Failure Mode, Effect and Criticality 
Analysis (FMECA). 

Failure Mode and Effect Analysis (FMEA): Ett 

systematiskt angreppssatt for att identifiera och 
analysera mojliga riskerforfelsymptom/felyttringar 
och for att forhindra att de uppstar. Se aven Failure 
Mode, Effects and Criticality Analysis (FMECA). 
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Failure Mode, Effects, and Criticality Analysis (FMECA): 

An extension of FMEA, as in addition to the basic FMEA, it 
includes a criticality analysis, which is used to chart the 
probability of failure modes against the severity of their 
consequences. The result highlights failure modes with 
relatively high probability and severity of consequences, 
allowing remedial effort to be directed where it will 
produce the greatest value. See also Failure Mode and 

Effect Ana lysis (FMEA). 

Failure Mode, Effects and Criticality Analysis 
(FMECA): En utokning av FMEA dar utokningen 
inkluderar en kritikalitetsanalys som anvands for att 
pavisa/kartlagga sannolikheten av att 
felsymptomslage intraffaroch allvarligheten i 
konsekvensav ett felsymptomslage. 1 resultatet 
framhavsfelsymptomslagen med relativ hog 
sannolikhet och allvarlighet i konsekvenserna, med 
hjalp av resultatet kan stodresurser och insatser 
fokuseras dar de harstorst varde.Se aven FMEA 
(Failure Mode and Effect Analysis). 

F 

failure rate: The ratio of the number of failures of a given 
category to a given unit of measure, e.g. failures per unit 
of time, failures per number of transactions, failures per 
number of computer runs. [IEEE 610] 

felfrekvens: Forhallandet mellan felsymptom av en 
viss kategori och en given matreferens, t.ex. 
felsymptom per tidsenhet, felsymptom per antal 
transaktioner, felsymptom per antal datorkorningar. 
[IEEE 610] 

ATM 

false-fail result: A test result in which a defect is reported 
although no such defect actually exists in the test object. 

falskt-underkant resultat: Ett test resultat dar en 

defekt ar rapporterad fastan det inte existerar nagon 
sadan defekt i testobjektet. 

ATM 

false-negative result: See false-pass result. 

falskt-negativt resultat: Se falskt-godkant resultat. 

ATM 

false-pass result: A test result which fails to identify the 
presence of a defect that is actually present in the test 
object. 

falskt-godkant resultat: Ett test resultat som 
misslyckas att identifiera narvaron av en defekt 
fastan defekten existerar i testobjektet. 

ATM 

false-positive result: See false-fail result. 

falskt-positivt resultat: Se falskt-underkant resultat. 

F 

fault: See defect. 

fel: En brist i en komponent eller ett system som kan 
fa komponenten eller systemet att misslyckas med 
att utfora sin onskade funktionalitet, t.ex. en felaktig 
kodsats eller data definition. Ett fel kan, om det 
upptrader under exekvering, orsaka ett 
felsymptom/en felyttring hos komponenten eller 
systemet. 

F 

fault attack: See attack. 

felattack: Se attack. 


fault density: See defect density. 

feltathet: Se defekttathet. 


Fault Detection Percentage (FDP): See Defect Detection 
Percentage (DDP). 

FDP (Fault Detection Percentage): Se DDP (Defect 
Detection Percentage). 


fault injection: The process of intentionally adding defects 
to a system for the purpose of finding out whether the 
system can detect, and possibly recover from, a defect. 

Fault injection intended to mimic failures that might occur 
in the field. See also fault tolerance. 

felinjektion: Processen att avsiktligt lagga in fel i ett 
system for att ta reda pa om systemet kan upptacka 
och eventuellt aterhamta sigfran felen. Felinjektion 
har for avsikt att efterlikna fel som kan uppsta i 
produktion. Se aven feltolerans. 
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fault masking: See defect masking. 

felmaskering: Intraffar narettfel doljer ett annatfel 
sa detta inte upptacks. 


fault seeding: The process of intentionally adding defects 
to those already in the component or system for the 
purpose of monitoring the rate of detection and removal, 
and estimating the number of remaining defects. Fault 
seeding is typically part of development (prerelease) 
testing and can be performed at any test level 
(component, integration, or system). [After IEEE 610] 23 

felplantering: Processen att avsiktligt lagga till fel 
utover de som redan finns i en komponent eller ett 
system i syfte att utvardera hur manga fel som hittas 
och tas bort, och for att uppskatta hur manga fel 
som finns kvar. Felplantering ar oftast en del av 
utvecklingstestningen (pa en forhandsversion) och 
kan utforas pa alia testnivaer (komponent, 
integration eller system) [efter IEEE 610] 23 

ATT 

fault seeding tool: A tool for seeding (i.e. intentionally 
inserting) faults in a component or system. 

felinjektionsverktyg: Verktyg for att injicera (d.v.s. 
avsiktligt infora) fel i en komponent eller ett system. 


fault tolerance: The capability of the software product to 
maintain a specified level of performance in cases of 
software faults (defects) or of infringement of its specified 
interface. [ISO 9126] See also reliability, robustness. 

feltolerans: 1) efter "fault tolerance": Kapacitet hos 
en programvaruprodukt att uppratthalla en 
specificerad prestandaniva da ett programvarufel 
upptrader eller da dess specificerade granssnitt inte 
foljs. [ISO 9126] Se aven tillforlitlighet, robusthet. 

2) efter "error tolerance": Kapacitet hos en 
komponent eller ett system att fortsatta normal drift 
trots att det finns felaktiga indata. [Efter IEEE 610] 

EITP 

Fault Tree Analysis (FTA): A technique used to analyze the 
causes of faults (defects). The technique visually models 
how logical relationships between failures, human errors, 
and external events can combine to cause specific faults to 

disclose. 

feltradsanalys, FTA (Fault Tree Analysis): En teknik 
som anvands for att analysera orsakerna till fel 
(defekter). Tekniken modellerar visuellt hur logiska 
relationer mellan felsymptom, manskliga misstag, 

och externa handelser kan i kombination orsaka 

specifikafel. 


feasible path: A path for which a set of input values and 
preconditions exists which causes it to be executed. 

mojlig vag: En vagfor vilken det finns invarden och 
forutsattningar som mojliggdr att vagen exekveras. 


feature: An attribute of a component or system specified 
or implied by requirements documentation (for example 
reliability, usability or design constraints). [After IEEE 

1008] 

finess: aven feature. Ett kannetecken hos en 

komponent eller ett system som har specificerade 
eller underforstadda krav (t.ex. tillforlitlighet, 
anvandbarhet eller designrestriktioner). [Efter IEEE 
1008] 

ETM 

feature-driven development: An iterative and incremental 
software development process driven from a client-valued 
functionality (feature) perspective. Feature-driven 
development is mostly used in agile software 
development. See also agile software development. 

funktionsdriven utveckling: En iterativ och 
inkrementell programutvecklingsprocess som drivs 
fran ett kundvarderatfunktionsperspektiv. 
Funktionsdriven utveckling anvands oftast i agil 
mjukvaruutveckling. Se aven agil 
programvaruutveckling. 

F 

field testing: See beta testing. 

falttestning: Se betatestning. 
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finite state machine: A computational model consisting of 

a finite number of states and transitions between those 

states, possibly with accompanying actions. [IEEE 610] 

begransad tillstandsmaskin: En datamodell som 
bestir av ett begransat antal tillstand och 
tillstandsovergangar mellan dessa tillstand, mbjligen 
med medfoljande handlingar (action). [IEEE 610] 


finite state testing: See state transition testing. 

testning av begransad tillstandsmaskin: Se 

tillstandsbaserad testning. 


fishbone diagram: See cause-effect diagram. 

fiskbensdiagram: Se orsak-verkandiagram. 

F 

formal review: A review characterized by documented 
procedures and requirements, e.g. inspection. 

formell granskning: En granskning som innebar att 
man har dokumenterade procedureroch kravfor 
granskning, t.ex. en inspektion. 


frozen test basis: A test basis document that can only be 
amended by a formal change control process. See also 
baseline. 

fryst testbas: Etttestbasdokument som bara kan 
andras genom en formell andringshanteringsprocess. 
Se aven faststalld konfiguration. 


Function Point Analysis (FPA): Method aiming to measure 
the size of the functionality of an information system. The 
measurement is independent of the technology. This 
measurement may be used as a basis for the 
measurement of productivity, the estimation of the 
needed resources, and project control. 

FPA (Function Point Analysis): aven 
funktionsgradsanalys. En metod som anvands for att 
mata mangden funktioner i ett informationssystem. 
Matningen ar oberoende av teknologi. Den har 
matningen kan anvandas som grund for matning av 
produktivitet, resursbehov och projektstyrning. 


functional integration: An integration approach that 
combines the components or systems for the purpose of 
getting a basic functionality working early. See also 
integration testing. 

funktionell integration: Etttillvagagangssattfbr 
integration dar komponenter eller system 
sammankopplas i syfte att fa en basfunktionalitet att 
fungera tidigt. Se aven integrationstestning. 

F 

functional requirement: A requirement that specifies a 
function that a component or system must perform. [IEEE 
610] 

funktionellt krav: Ett krav som specificeraren 
funktion som en komponent eller ett system maste 
utfora. [IEEE 610] 


functional test design technique: Procedure to derive 
and/or select test cases based on an analysis of the 
specification of the functionality of a component or 
system without reference to its internal structure. See also 
black box test design technique. 

funktionell testdesignteknik: Proceduren att 
utveckla och/ellervaljatestfall baserat pa en analys 
av specifikationen eller funktionaliteten hos 
komponenten eller systemet utan hanvisning till den 

interna strukturen. Se aven black-box- 

testdesignteknik. 

F 

functional testing: Testing based on an analysis of the 
specification of the functionality of a component or 
system. See also black box testing. 

funktionstestning: Testning av systemets 
funktionella egenskaper baserat pa en analys av 
funktionsspecifikationer for en komponent eller ett 
system. Se aven black-box-testning. 


functionality: The capability of the software product to 
provide functions which meet stated and implied needs 
when the software is used under specified conditions. [ISO 
9126] 

funktionalitet: Programvaruproduktens kapacitet att 

tillhandahalla funktioner som motsvarar stallda och 

underforstadda behov nar programvaran anvands 
under definierade forhallanden. [ISO 9126] 
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functionality testing: The process of testing to determine 
the functionality of a software product. 

funktionalitetstestning: Testning for att faststalla 
funktionaliteten hos en programvaruprodukt. 


G 



glass box testing: See white box testing. 

glasbox-testning: Se white-box-testning. 

EITP 

Goal Question Metric: An approach to software 
measurement using a three-level model: conceptual level 
(goal), operational level (question) and quantitative level 
(metric). 

Goal Question Metric: En 

programvarumatningsmetod indelad i tre nivaer: 
begreppsmassig niva (malorientering - "goal"), 
operativ niva (frageoCentering - "question"), 
kvantifieringsniva (matorientering - "metric"). 

EITP 

GQM: See Goal Question Metric. 

GQM: Se Goal Question Metric. 


H 



hardware-software integration testing: Testing 
performed to expose defects in the interfaces and 
interaction between hardware and software components. 
See also integration testing. 

integrationstestning for hard- och mjukvara: 

Testning utford for att avsloja defekter i granssnitt 
och samspel mellan hardvara och mjukvara. Se aven 
integrationstestning. 


hazard analysis: A technique used to characterize the 
elements of risk. The result of a hazard analysis will drive 
the methods used for development and testing of a 
system. See also risk analysis. 

analys av risker som kan leda till skada eller fara for 
liv: En teknik som anvands for att utmarka 

riskbenagna delar. Resultatet av analysen padriver 
anvanda metoder for utveckling och testning av 
system. Se aven riskanalys. 

ATA 

heuristic evaluation: A usability review technique that 
targets usability problems in the user interface or user 
interface design. With this technique, the reviewers 
examine the interface and judge its compliance with 
recognized usability principles (the "heuristics"). 

heuristisk evaluering av anvandargranssnitt: En 

teknik for att bedoma anvandbarhet utifran 

anvandbarhetsproblem eller design av 
anvandargranssnitt. Med denna teknik undersoker 
granskarna granssnittet och bedomerdess 

overensstammelse med erkanda 
anvandbarhetsprinciper ("heuristiken"). 

ATA 

high level test case: A test case without concrete 
(implementation level) values for input data and expected 
results. Logical operators are used; instances of the actual 
values are not yet defined and/or available. See also low 

level test case. 

hognivatestfall: Etttestfall utan konkreta varden (pa 
implementationsniva) for indata eller resultat. Se 
aven lagnivatestfall. 
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horizontal traceability: The tracing of requirements for a 
test level through the layers of test documentation (e.g. 
test plan, test design specification, test case specification 
and test procedure specification or test script). 

horisontell sparbarhet: Sparning av krav for en 
testniva genom de olika nivaerna av 
testdokumentation (t.ex. testplan, testdesign, 
testspecifikation, testfall, testprocedur och/eller 
testskript). 

Kommentar: Betyderofta att man i praktiken satter 
ett unikt nummerfor varje krav, (eller designobjekt 
o.s.v.) och varje dokument refererartillbaka till det 
kravets unika nummer. Saledes kan man spara ett 
testfall till dess ursprungliga krav. Notera att det ar 
mojligt att skapa testfall som saknar direkt koppling 
till krav, designobjekt eller liknande. 


hyperlink: A pointer within a web page that leads to other 
web pages. 

hyperlank: En lank (pekare) inom en webbsida som 
ledertill en annan webbsida. 

ATT 

hyperlink test tool: A tool used to check that no broken 
hyperlinks are present on a web site. 

hyperlank-testverktyg: Ett verktyg som kontrollerar 
att alia hyperlankararfungerande. 

Kommentar: Ett hyperlankverktyg kontrollerar att 
alia lankar leder till en existerande webbsida. 

Verktyget kan inte avgora om det ar ratt webbsida 
som lanken ledertill. 


1 


EITP 

IDEAL: An organizational improvement model that serves 
as a roadmap for initiating, 

planning, and implementing improvement actions. The 
IDEAL model is named for the five 

phases it describes: initiating, diagnosing, establishing, 
acting, and learning. 

IDEAL: En modell for organisationsforbattringar 
vilken tjanarsom en guide vid initiering, planering 
och genomforande avforbattringsaktiviteter. IDEAL- 
modellens namn kommer av dess fern faser: 

initiering, diagnostisering, etablering, agerande och 

larande. 

F 

impact analysis: The assessment of change to the layers of 
development documentation, test documentation and 
components, in order to implement a given change to 
specified requirements. 

paverkansanalys: Bedomningen av hur omfattande 
andringar av utvecklingsdokumentation, 
testdokumentation och komponentersom behovs, 
for att genomfora en viss forandring med 
specificerade krav. 

F 

incident: Any event occurring that requires investigation. 
[After IEEE 1008] 

incident: Se avvikelse. 

F 

incident logging: Recording the details of any incident that 
occurred, e.g. during testing. 

avvikelseloggning: Att skriva logg over handelser 
eller avvikelser, ibland aven handelseloggning. 

F 

incident management: The process of recognizing, 
investigating, taking action and disposing of incidents. It 
involves logging incidents, classifying them and identifying 
the impact. [After IEEE 1044] 

avvikelsehantering: Se felhantering (eng. defect 
management). 
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F 

incident management tool: A tool that facilitates the 
recording and status tracking of incidents. They often have 

workflow-oriented facilities to track and control the 

allocation, correction and re-testing of incidents and 
provide reporting facilities. See also defect management 

tool. 

avvikelsehanteringsverktyg: Se felhanteringsverktyg 
(eng. defect management tool). 

F 

incident report: A document reporting on any event that 
occurred, e.g. during the testing, which requires 
investigation. [After IEEE 829] 25 

avvikelserapport: Aven felrapport. Ett dokument 
som rapporterar om en avvikelse eller handelse som 
intraffat under t.ex. testningoch som kraveren 
utredning. [Efter IEEE 829]. Se aven felrapport. 

F 

incremental development model: A development lifecycle 
where a project is broken into a series of increments, each 
of which delivers a portion of the functionality in the 
overall project requirements. The requirements are 
prioritized and delivered in priority order in the 
appropriate increment. In some (but not all) versions of 
this lifecycle model, each subproject follows a 'mini V- 
model' with its own design, coding and testing phases. 

modell for inkrementell utveckling: En 

utvecklingsmodell dar projekt delas upp i en serie av 
inkrement, dar varje inkrement levererar en del av 
funktionaliteten som ingar i projektkraven. Kraven 
prioriteras och levereras i prioriteringsordning i det 
tilldelade inkrementet. 1 vissa, men inte alia, 
versioner av projektets livscykel foljer man en "mini- 
V-modell", med egna faser for design, kodning och 
testning. 


incremental testing: Testing where components or 
systems are integrated and tested one or some at a time, 
until all the components or systems are integrated and 

tested. 

inkrementell testning: Testning dar komponenter 
eller system integreras och testas, ett eller flera i 
taget, tills alia komponenter eller system har 
integrerats och testats. 

F 

ATM 

independence of testing: Separation of responsibilities, 
which encourages the accomplishment of objective 
testing. [After DO-178b] 

oberoende testning: Separation av ansvar, vilket 
sakerstaller att man uppfyller kravet pa en objektiv 
testning. [Efter DO-178b] 

Kommentar: 1 detta (test)sammanhang syftas oftast 
pa revision av ett system, eller pa testfall, eller 
testorganisationens uppdelning i nivaer. 

EITP 

indicator: A measure that can be used to estimate or 

predict another measure. [ISO 14598] 

indikator: Matetal som kan anvandas for att 

uppskatta eller forutsaga ett annat matetal. [ISO 
14598] 


infeasible path: A path that cannot be exercised by any 
set of possible input values. 

onabar vag: En exekveringsvag som det ar omojligt 
att na, oberoende av vilken kombination av invarden 
som valjs. 

F 

ATM 

informal review: A review not based on a formal 

(documented) procedure. 

informell granskning: En granskning som inte 
baseras pa en formell (dokumenterad) procedur. 
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EITP 

initiating (IDEAL): The phase within the IDEAL model 

where the groundwork is laid for a 

successful improvement effort. The initiating phase 

consists of the activities: set context, 

build sponsorship and charter infrastructure. See also 

IDEAL. 

initiering (IDEAL): Den fas inom IDEAL modellen i 
vilken man laggergrundenforenframgangsrik 
forbattringsaktivitet. Initieringsfasen bestarav 
aktiviteterna: faststall sammanhang, etablera stod 
fran ledningen samt faststall nodvandig 

infrastruktur. Se aven IDEAL. 


input: A variable (whether stored within a component or 
outside) that is read by a component. 

indata: En variabel som hartilldelats ett varde 

(oavsett hur den ar lagrad eller atkomstmetod) nar 
den lases/anvands under exekveringen. Se aven 
invarde. 


input domain: The set from which valid input values can 

be selected. See also domain. 

indatadoman: Den uppsattning data fran vilken 
giltiga indata kan valjas. Se aven doman. 


input value: An instance of an input. See also input. 

invarde: Varden som ges till ett program, system 

eller testfall. Se aven indata. 



Kommentar: Ordets innebord framgar ofta av 
sammanhanget, annars bor man specificera vilka 

indata eller invarden som avses. 


insourced testing: Testing performed by people who are 
co-located with the project team but are not fellow 
employees. 

inhyrd testning: aven insourced testning. Testning 

som utfors av manniskor som ar samlokaliserade 
med projektgruppen, men inte arbetskamrater. 

F 

ATM 

EITP 

inspection: A type of peer review that relies on visual 
examination of documents to detect defects, e.g. 
violations of development standards and non¬ 
conformance to higher level documentation. The most 
formal review technique and therefore always based on a 
documented procedure. [After IEEE 610, IEEE 1028] See 
also peer review. 

inspektion: En typ av kollegial granskning som 
innefattar en visuell undersokning av dokument med 
syfte att hitta fel, t.ex. avvikelser fran 
utvecklingsstandarder eller att dokumentet inte 
foljer dokumentation fran hogre nivaer. Det ar den 
mestformella granskningstekniken och baseras 
darfor alltid pa en dokumenterad procedur. [Efter 

IEEE 610, IEEE 1028] Se aven kollegial granskning. 


inspection leader: See moderator. 

inspektionsledare: Se moderator. 


inspector: See reviewer. 

inspektor: Se granskare. 

ATT 

installability: The capability of the software product to be 
installed in a specified environment [ISO 9126]. See also 
portability. 

installationsbarhet: Formagan hos en 
programvaruprodukt att kunna installeras i en 
specificerad miljd. [ISO 9126] Se aven portabilitet. 


installability testing: The process of testing the 
installability of a software product. See also portability 
testing. 

testning av installationsbarhet: Testning av en 
programvaruprodukts installationsbarhet. Se aven 
portabilitetstestning. 
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installation guide: Supplied instructions on any suitable 
media, which guides the installer through the installation 
process. This may be a manual guide, step-by-step 
procedure, installation wizard, or any other similar process 
description. 

installationshandledning: Tillhandahallna 
instruktioner, pa lampligt medium, som leder 
installatoren genom installationsprocessen. Det kan 
vara en manuell handledning, en steg-for-steg- 
procedur, automatisk hjalp eller liknande 
processbeskrivning. 


installation wizard: Supplied software on any suitable 
media, which leads the installer through the installation 
process. It normally runs the installation process, provides 
feedback on installation results, and prompts for options. 

installations-wizard: aven installationsguide. 
Tillhandahallen programvara pa lampligt medium 
som leder installatoren genom 
installationsprocessen. Normalt genomfor 
programvaran installationsprocessen och atermatar 
information om installationsresultat samt visar 

valmojligheter under installationens gang. 


instrumentation: The insertion of additional code into the 

program in order to collect information about program 
behavior during execution, e.g. for measuring code 

coverage. 

instrumentering: Inforande av extra kod i 
programmet for att gora det mojligt att skaffa 
information om programmets beteende under 
exekvering, t.ex. for att mata kodtackning. 


instrumenter: A software tool used to carry out 

instrumentation. 

instrument: Ett verktygfor programvara som 
anvands for att utfora instrumenteringar av kod. Se 
aven instrumentering. 


intake test: A special instance of a smoke test to decide if 
the component or system is ready for detailed and further 
testing. An intake test is typically carried out at the start of 
the test execution phase. See also smoke test. 

oppningstest: Ett exempel pa roktest med syfte att 
avgora om en komponent eller ett system ar redo for 
finjustering eller fortsatt testning. En oppningstest ar 
typiskt nagot som utfors i borjan av en 
testexekveringsfas. Se aven roktest. 

F 

integration: The process of combining components or 
systems into larger assemblies. 

integration: Processen att kombinera komponenter 
eller system till storre grupper, objekt eller enheter. 

F 

integration testing: Testing performed to expose defects 

in the interfaces and in the interactions between 

integrated components or systems. See also component 
integration testing, system integration testing. 

integrationstestning: Testning utford med syfte att 
hittafel i granssnitt och kommunikation mellan 
programkomponenter, men aven mellan program 
och maskinkomponenter som ar integrerade. 
Integrationstest omfattar ocksa i en V-modell att 
verifiera att designstrukturen motsvarar 
integrationen. Se aven 
ko m po nenti ntegratio nstestn i ng, 
systemintegrationstestning. 


integration testing in the large: See system integration 
testing. 

overgripande integrationstestning: Se 

systemintegrationstestning. 


integration testing in the small: See component 
integration testing. 

detaljerad integrationstestning: Se 

komponentintegrationstestning. 
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interface testing: An integration test type that is 
concerned with testing the interfaces between 
components or systems. 

granssnittstestning: aven gransytetestning. En typ av 
integrationstest som beror testning av gransytor 
mellan komponenteroch system. 


interoperability: The capability of the software product to 
interact with one or more specified components or 
systems. [After ISO 9126] See also functionality. 

interoperabilitet: Programvarans kapacitet att 
samverka med en ellerflera specificerade 
komponenter eller system. [Efter ISO 9126] Se aven 
funktionalitet. 

F 

ATA 

interoperability testing: The process of testing to 
determine the interoperability of a software product. See 
also functionality testing. 

interoperabilitetstestning: aven samarbetstestning. 
Testning av systemet eller komponentens 
samverkanskapacitet. Se aven 
funktionalitetstestning. 

Kommentar: Formagan hostva ellerflera system 
eller komponenter att utbyta information och att 
sedan anvanda denna information, samt att 
systemen tolkar informationen pa samma satt. 


invalid testing: Testing using input values that should be 
rejected by the component or system. See also error 
tolerance, negative testing. 

ogiltighetstestning: Testning med invarden som inte 
bor tolereras av komponenten eller systemet. Se 
aven feltolerans, negativ testning. 

ETM 

Ishikawa diagram: See cause-effect diagram. 

Ishikawa-diagram: Se orsak-verkandiagram. 


isolation testing: Testing of individual components in 
isolation from surrounding components, with surrounding 
components being simulated by stubs and drivers, if 
needed. 

enskild testning: Testning av enskilda komponenter 
skilda fran intilliggande komponenter, dar de 
intilliggande komponenterna simuleras av stubbar 
eller drivrutiner om nodvandigt. 


item transmittal report: See release note. 

leveransrapport for element: Se leveransdokument. 

F 

iterative development model: A development lifecycle 
where a project is broken into a usually large number of 
iterations. An iteration is a complete development loop 
resulting in a release (internal or external) of an 
executable product, a subset of the final product under 
development, which grows from iteration to iteration to 
become the final product. 

modell for iterativ utveckling: En process for 
utveckling dar ett projekt ar indelat i ett antal, 
vanligtvis manga, iterationer. En iteration ar ett 
fullstandigt utvecklingsvarv som resulterar i en 
utgava (intern eller extern) av en exekverbar 
produkt. En delmangd av den slutliga produkten 
vaxer fram for varje iteration for att till sist utgora 
den slutliga produkten. 


K 



key performance indicator: See performance indicator. 

nyckelprestandatal: Se prestandatal. 

F 

ATA 

ATT 

keyword-driven testing: A scripting technique that uses 
data files to contain not only test data and expected 
results, but also keywords related to the application being 
tested. The keywords are interpreted by special 
supporting scripts that are called by the control script for 
the test. See also data-driven testing. 

nyckelordsdriven testning: En testteknik dar man 
valjertestfall baserat pa vissa nyckelord, ofta 
affarsdrivet och kopplat till den funktionella och 
logiska anvandningen av systemet. Se aven 
datadriven testning. 
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L 



LCSAJ: A Linear Code Sequence And Jump, consists of the 
following three items (conventionally identified by line 
numbers in a source code listing): the start of the linear 
sequence of executable statements, the end of the linear 
sequence, and the target line to which control flow is 
transferred at the end of the linear sequence. 

LCSAJ (Linear Code sequence and Jump), sekventiell 
kod med hopp: En kodradsnumrering i en 
kallkodslistning eller i kodblocket, som bestar av tre 
delar: starten av kodblocket eller listningen som 
beskriversekvensen av exekverbara kodrader, slutet 
av kodblocket i listan, samt den adress till vilket 

kontrollflddet overfors i slutet av kodsekvensen. 


LCSAJ coverage: The percentage of LCSAJs of a component 
that have been exercised by a test suite. 100% LCSAJ 
coverage implies 100% decision coverage. 

LCSAJ-tackning, tackning av sekventiell kod med 
hopp: Hur manga procent av LCSAJ som har blivit 

exekverat av en testsvit. 100% LCSAJ innebar ocksa 
100% grenvillkorstackning. 


LCSAJ testing: A white box test design technique in which 
test cases are designed to execute LCSAJs. 

LCSAJ-testning: En strukturell testdesignteknik dar 
testfall ar konstruerade med avsikt att uppfylla 
LCSAJ-tackning. Se aven LCSAJ-tackning. 

EITP 

lead assessor: The person who leads an assessment. In 
some cases, for instance CMMi and TMMi when formal 
assessments are conducted, the lead assessor must be 
accredited and formally trained. 

utvarderingsledare: Den person som leder en 
processutvardering. 1 vissa fall, t.ex. i CMMi och 

TMMi, vilka innehallerformella utvarderingar, maste 
huvudprocessutvarderaren vara formellt utbildad 

och ackrediterad. 

ATA 

learnability: The capability of the software product to 
enable the user to learn its application. [ISO 9126] See also 
usability. 

inlarningsmojlighet: Kapaciteten hosen 
programvaruprodukt att mojliggdra for anvandaren 
att lara sig dess funktionaliteter. [ISO 9126] Se aven 
anvandbarhet. 

EITP 

learning (IDEAL): The phase within the IDEAL model where 
one learns from experiences 

and improves one's ability to adopt new processes and 
technologies in the future. The 
learning phase consists of the activities: analyze and 
validate, and propose future actions. 

See also IDEAL. 

larande (IDEAL): Den fas inom IDEAL modellen i 

vilken man lar av erfarenheter och forbattrar sina 

mojligheter att anpassa sig till nya processer och 
teknologier i framtiden. Larande-fasen bestar av 
aktiviteterna: analysera och validera samtformulera 
framtida aktiviteter. Se aven IDEAL. 

ATM 

level test plan: A test plan that typically addresses one 
test level. See also test plan. 

nivatestplan: En testplan som vanligtvis beror en 
enskild testniva. Se aven testplan. 

EITP 

lifecycle model: A partitioning of the life of a product or 
project into phases. [CMMI] See also software lifecycle. 

livscykelmodell: En uppdelning i faser av livstiden 
hos en produkt eller ett projekt.[CMMI]. Se aven 
livscykel for programvara. 


link testing: See component integration testing. 

kopplingstestning: Se 

komponentintegrationstestning. 
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load profile: A specification of the activity which a 
component or system being tested may experience in 
production. A load profile consists of a designated number 
of virtual users who process a defined set of transactions 
in a specified time period and according to a predefined 
operational profile. See also operational profile. 

lastprofil: En specifikation over de aktivitetersom 
kan intraffa vid anvandning och som ska utforas vid 
test av en komponent eller ett system. En lastprofil 
innehallerett antal virtuella anvandare som utforen 
mangd transaktioner inom en specificerad tidsperiod 
och enligt en fordefinierad driftsprofil. Se aven 
driftsprofil. 

F 

load testing: A type of performance testing conducted to 
evaluate the behavior of a component or system with 
increasing load, e.g. numbers of parallel users and/or 
numbers of transactions, to determine what load can be 
handled by the component or system. See also 
performance testing, stress testing. 

lasttestning: En typ av prestandatestning som 
utvarderar komponentens eller systemets 
upptradande med vaxande last, t.ex. antalet 
parallella anvandare och/eller antalet transaktioner, 
for att se vilken last som kan hanteras av 

komponenten eller systemet. Se aven 
prestandatestning, stresstestning. 

F 

load testing tool: A tool to support load testing whereby it 
can simulate increasing load, e.g., numbers of concurrent 
users and/or transactions within a specified time-period. 

See also performance testing tool. 

lasttestverktyg: Ett verktyg som stodjer lasttestning 
och kan simulera en vaxande last, t.ex. antalet 
parallella anvandare och/eller antalet transaktioner 
inom en specificerad tidsperiod. Se aven 
prestandatestverktyg. 

ATA 

logical test case: See high level test case. 

logiktestfall: Se hognivatestfall. 


logic-coverage testing: See white box testing. [Myers] 

logiktackande testning: Se white-box-testning. 

[Myers] 


logic-driven testing: See white box testing. 

logikdriven testning: Se white-box-testning. 

ATA 

low level test case: A test case with concrete 

(implementation level) values for input data and expected 
results. Logical operators from high level test cases are 
replaced by actual values that correspond to the 
objectives of the logical operators. See also high level test 

lagnivatestfall: Ett testfall med konkreta 
(implementationsniva) varden for indata och 
forvantat resultat. Logiska operatorerfran 
hognivatestfall ersatts med ratta varden som 
motsvararsyftet med de logiska operatorerna. Se 
aven hognivatestfall. 


M 



maintainability: The ease with which a software product 
can be modified to correct defects, modified to meet new 
requirements, modified to make future maintenance 
easier, or adapted to a changed environment. [ISO 9126] 

underhallbarhet: Hur latt en programvara kan 
modifieras for att ratta fel, tillgodose nya krav, 
underlatta framtida underhall eller anpassa till 
forandrad miljo. [ISO 9126] 

Kommentar: Med miljo menas harden miljo som 
programvaran anvands i, dvs. datoreroch 
kringutrustning som programvaran ar beroende av. 
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F 

ATT 

maintainability testing: The process of testing to 
determine the maintainability of a software product 

underhallbarhetstestning: Testprocess for att 

bestamma underhallbarheten hos en 

programvaruprodukt. 

Kommentar: Nagra specifika forvaltningsmal kan 
vara att det finns dokumentation, testfall och 
kunskap om hur systemet ar uppbyggt. 


maintenance: Modification of a software product after 
delivery to correct defects, to improve performance or 
other attributes, or to adapt the product to a modified 
environment. [IEEE 1219] 28 

underhall: aven forvaltning. Modifiering av en 
programvaruprodukt efter leverans for att ratta 
defekter, forbattra prestanda eller andra 
egenskaper, eller anpassa produkten till en 
forandrad miljo. [IEEE 1219] 

Kommentar: Med miljo menas harden miljo som 
programvaran anvands i, dvs. datoreroch 
kringutrustning som programvaran ar beroende av. 

F 

maintenance testing: Testing the changes to an 
operational system or the impact of a changed 
environment to an operational system. 

underhallstestning: aven forvaltningstestning. Test 
av modifiering av ett system som tagits i drift eller 
test av hur en andrad omgivning paverkarett 
drifttaget system. 


man in the middle attack: The interception, mimicking 
and/or altering and subsequent relaying of 
communications (e.g., credit card transactions) by a third 
party such that a user remains unaware of that third 
party's presence. 

MITM-attack: Aven janusattack. Avlyssning, 
harmning och/eller andring och efterfoljande 
formedling av kommunikation (t.ex. 
kreditkortstransaktioner) utford av en tredje part sa 
att en anvandare ar omedveten om den tredje 
parten narvaro. 

ATM 

management review: A systematic evaluation of software 
acquisition, supply, development, operation, or 
maintenance process, performed by or on behalf of 
management that monitors progress, determines the 
status of plans and schedules, confirms requirements and 
their system allocation, or evaluates the effectiveness of 
management approaches to achieve fitness for purpose. 
[After IEEE 610, IEEE 1028] 

administrationsgranskning: En systematisk 
granskning av programinkop, orderhantering, 
utveckling, drift och underhall som overvakar 
vidareutvecklingen och konstaterar krav och 
tillhorande systembehov. Utvecklareffektiviteten 
hos administrativa rutineroch hanteringsprocesser 
for att de ska uppna basta resultat for sitt syfte. 

[Efter IEEE 610, IEEE 1028] 

EITP 

manufacturing-based quality: A view of quality, whereby 
quality is measured by the degree to which a product or 
service conforms to its intended design and requirements. 
Quality arises from the process(es) used. [After Garvin] 

See also product-based quality, transcendent-based 
quality, user-based quality, value-based quality. 

tillverkningsbaserad kvalitet: Ett satt att se pa 
kvalitet som innebar att kvaliteten hos en produkt 
eller tjanst avgors av i vilken grad den stammer 
overens med dess ursprungliga design och krav. 
Kvaliteten i produkten uppkommergenom de 
anvanda utvecklings- eller tillverkningsprocesserna. 
[Efter Garvin] Se aven anvandarbaserad kvalitet, 
produktbaserad kvalitet, upplevd kvalitet och 

vardebaserad kvalitet. 

ATM 

master test plan: A test plan that typically addresses 
multiple test levels. See also test plan. 

dvergripande testplan: En testplan som normalt 
riktar sig mot flera testnivaer. Se aven testplan. 
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ATT 

maturity: (1) The capability of an organization with 
respect to the effectiveness and efficiency of its processes 
and work practices. See also Capability Maturity Model 
Integration, Test Maturity Model integration. (2) The 
capability of the software product to avoid failure as a 
result of defects in the software. [ISO 9126] See also 
reliability. 

mognad: (1) Formagan hos en organisation med 
avseende pa hur verksamma och effektiva dess 
processer och arbetssatt ar. Se aven Capability 
Maturity Model Integration, Test Maturity Model 
Integration. 

(2) Kapacitet hos en programvaruprodukt att 
undvika negativa effekter som foljd av fel i 
programvara. [ISO 9126] Se aven tillforlitlighet. 

EITP 

maturity level: Degree of process improvement across a 
predefined set of process areas in which all goals in the set 
are attained. [TMMi] 

mognadsniva: Uppnadd processforbattringsgrad 
over en fordefinierad mangd processomraden, i vilka 
alia mognadsmal for alia processomraden maste 
vara uppnadda. [TMMi] 


maturity model: A structured collection of elements that 
describe certain aspects of maturity in an organization, 
and aid in the definition and understanding of an 
organization's processes. A maturity model often provides 
a common language, shared vision and framework for 
prioritizing improvement actions. 

mognadsmodell: En strukturerad samling aspekter 
som beskriver en organisations mognad som aven 

kan anvandas for att definiera och forsta en 

organisations processer. En mognadsmodell 
tillhandahaller ofta ett gemensamt sprak, en delad 
vision och ett ramverk for att prioritera 
forbattringsaktiviteter. 


MCDC: See modified condition decision coverage. 

MCDC: Se Modifierad testning av villkorsbeslut. 


Mean Time Between Failures: The arithmetic mean 

(average) time between failures of a system. The MTBF is 
typically part of a reliability growth model that assumes 
the failed system is immediately repaired, as a part of a 
defect fixing process. See also reliability growth model. 

Mean Time Between Failures: Genomsnittstid 

mellan tva pa varandra foljande felsymptom. MTBF 
anvands typiskt i en Reliability Growth Model dar 
man antarattavvikelsen omedelbart repareras, som 
del avfelrattningsprocessen. Se aven Reliability 

Growth Model. 


Mean Time To Repair: The arithmetic mean (average) 
time a system will take to recover from any failure. This 
typically includes testing to insure that the defect has 

been resolved. 

Mean Time To Repair: Genomsnittstid dettarfran 
en felyttring tills dess att motsvarande defekt ar 
atgardad, inklusive tiden det tar att testa att 
defekten har atgardats. 

EITP 

measure: The number or category assigned to an attribute 
of an entity by making a measurement. [ISO 14598] 

matt: Ett matvarde (numeriskt varde) eller kategori 
som man tilldelar en egenskap hos en enhet genom 
att utfora matning. [IS014598] 


measurement: The process of assigning a number or 
category to an entity to describe an attribute of that 
entity. [ISO 14598] 

matning: Processen (utforandet) att tilldela ett 
numeriskt varde eller en kategori till en enhet for att 
beskriva en egenskap hos enheten. [IS014598] 


measurement scale: A scale that constrains the type of 
data analysis that can be performed on it. [ISO 14598] 

matningsskala: En skala som bestammer vilka 
begransningar som galler for analys av data. 

[IS014598] 
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ATT 

memory leak: A memory access failure due to a defect in a 
program's dynamic store allocation logic that causes it to 
fail to release memory after it has finished using it, 
eventually causing the program and/or other concurrent 
processes to fail due to lack of memory. 

minneslacka: En minnesatkomstavvikelse som 

orsakas av en defekt i ett programs dynamiska 
minneshantering vilken innebar att en process 
misslyckas med att frigora minne efter anvandning. 

Kan leda till att programmet och/eller andra 
samtidigt exekverande processer havererar pa grund 
av minnesbrist. 

ETM 

methodical testing: Testing based on a standard set of 
tests, e.g., a checklist, a quality standard, or a set of 
generalized test cases. 

metodisk testning: Testning baserad pa en 
standarduppsattning av tester, t.ex. en checklista, en 
kvalitetsnorm, eller en uppsattning generella testfall. 

F 

EITP 

metric: A measurement scale and the method used for 

measurement. [ISO 14598] 

matetal: Ett varde som anger hur manga ganger den 
valda enheten ingar i ett matvarde eller en storhet. 
[IS014598] 


migration testing: See conversion testing. 

migrationstestning: aven oversattningstestning. Se 
konverteringstestning. 


milestone: A point in time in a project at which defined 
(intermediate) deliverables and results should be ready. 

milstolpe: Ett delmal i ett projekt, som oftast ska 
vara uppfyllt innan man gar vidare i projektet. 

EITP 

mind map: A diagram used to represent words, ideas, 
tasks, or other items linked to and arranged around a 
central keyword or idea. Mind maps are used to generate, 
visualize, structure, and classify ideas, and as an aid in 
study, organization, problem solving, decision making, and 
writing. 

mind-map: Ett diagram som anvands for att 
representera begrepp, ideer, aktiviteter eller andra 
saker, som ar kopplade till eller arrangerade kring ett 
nyckelord eller en central ide. Mind-maps anvands 
for att generera, visualisera, strukturera och 
klassificera ideer samt som en hjalp vid instudering, 
organisering, problemlosning, beslutsfattande och 
vid skrivande. 

F 

mistake: See error. 

manskligt misstag: Se misstag. 

ETM 

model-based testing: Testing based on a model of the 
component or system under test, e.g., reliability growth 
models, usage models such as operational profiles or 

behavioral models such as decision table or state 
transition diagram. 

Modellbaserad testning: Testning baserad pa en 
modell av komponenten eller systemet som testas, 
t.ex. reliability growth model, anvandningsmodeller 
som driftsprofiler eller beteendemodeller som 
beslutstabell eller tillstandsbaserad testning. 

F 

modeling tool: A tool that supports the creation, 

amendment and verification of models of the software or 

system [Graham]. 

modelleringsverktyg: Ett verktyg som stodjer 
skapande, forandring och verifiering av modeller for 
program eller system. [Graham] 

F 

ATM 

moderator: The leader and main person responsible for an 
inspection or other review process 

moderator: Den person som ar ledare och 
huvudansvarigforen inspektion eller annan 
granskningsprocess. 


modified condition decision coverage: The percentage of 
all single condition outcomes that independently affect a 
decision outcome that have been exercised by a test case 
suite. 100% modified condition decision coverage implies 
100% decision condition coverage. 

modifierad tackning av villkorsbeslut: Procent av 
alia villkorsbeslut, som oberoende paverkar 
kodgrenval exekverat av testfallssviten. 100 % MCDC 
tackning medfor 100 % bagtackning. 
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modified condition decision testing: A white box test 
design technique in which test cases are designed to 
execute single condition outcomes that independently 

affect a decision outcome. 

modifierad testning av villkorsbeslut: En testteknik 
dar testfall ar avsedda att exekvera villkor som 

paverkar kodgrensvalet i programkod. Varje 
villkorsresultat paverkar valet av kodgren. 


modified multiple condition coverage: See modified 
condition decision coverage. 

modifierad tackning av villkorskombinationer: Se 

modifierad tackning av villkorsbeslut 


modified multiple condition testing: See modified 
condition decision testing. 

modifierad testning av villkorskombinationer: Se 

modifierad testning av villkorsbeslut 


module: See component. 

modul: Se komponent. 


module testing: See component testing. 

modultestning: Se komponenttestning. 


monitor: A software tool or hardware device that runs 

concurrently with the component or system under test 
and supervises, records and/or analyses the behavior of 
the component or system. [After IEEE 610] 

overvakare: Programvaruverktyg eller 
hardvaruenhet som anvands samtidigt med en 
komponent eller system vid testning och som 
overvakar, spelar in och/elleranalyserar beteendet 
hos komponenten eller systemet. [Efter IEEE 610] 

F 

monitoring tool: See monitor. 

overvakningsverktyg: Se overvakare. 


monkey testing: Testing by means of a random selection 
from a large range of inputs and by randomly pushing 
buttons, ignorant of how the product is being used. 

aptestning: Testning med slumpvis urval av ett stort 
omfang invarden och med slumpvisa 
knapptryckningar utan hansyn till hur produkten 

normalt anvands. 


MTBF: See Mean Time Between Failures. 

MTBF: Se Mean Time Between Failures. 


MTTR: See Mean Time To Repair. 

MTTR: Se Mean Time To Repair. 


multiple condition: See compound condition. 

kombinationsvillkor: Se multipla villkor. 


multiple condition coverage: The percentage of 
combinations of all single condition outcomes within one 
statement that have been exercised by a test suite. 100% 
multiple condition coverage implies 100% modified 
condition decision coverage. 

villkorskombinationstackning: Den procentuella 
tackningen av kombinationen av alia villkor i ett 
kodgrensvillkor som finns i en kodrad och dess 

resultat som har exekverats av en testfallssvit. Med 

100 % tackning av villkorskombinationer ar det 
underforstatt att 100 % MCDC tackning ocksa har 
uppfyllts. Se aven kodtackning av kombinationer av 
kodgrenvillkor. 

ATT 

multiple condition testing: A white box test design 
technique in which test cases are designed to execute 
combinations of single condition outcomes (within one 
statement). 

villkorskombinationstestning: En strukturell 
testteknik dartestfallen designas for att exekvera 
kombinationer av enstaka villkorsresultat, villkor 

som finns i en sats. 
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mutation analysis: A method to determine test suite 
thoroughness by measuring the extent to which a test 
suite can discriminate the program from slight variants 
(mutants) of the program. 

mutationsanalys: Metod som anvands nar man vill 
avgora fullstandigheten hos en testfallssvit genom 
att mata i vilken grad den kan sarskilja olika varianter 
(mutanter) av programmet. Se aven felplantering. 

Kommentar: Malet med mutationstestning ar att 
skaffa en komplett testsvit som "fullstandigt" testar 
en aspekt av programmet/systemet. Man jamfortva 
varianter av systemet, ett korrekt och en variation av 
programmet/systemet, sida vid sida. Om testsviten 
inte hittar nagon skillnad pa den "ratta" varianten 
och den som har varierats "felaktigt" sa har man en 
mutant. Darefter ska pas ett nytt testfall, som inte 
godkanner mutanten, och adderas till testsviten. 

Denna proceduratt hitta mutanter borgoras 
automatiskt och sker vanligen pa kodniva. Att hitta 
testfall kan ibland vara svart att gora automatiskt. 


mutation testing: See back-to-backtesting. 

mutationstestning: aven komparativtestning. Se 
sida-vid-sida testning. 

ETM 

Myers-Briggs Type Indicator (MBTI): An indicator of 
psychological preference representing the different 
personalities and communication styles of people. 

Myers-Briggs Type Indicator (MBTI): Ett matt pa 
psykologiska preferensersom representerar olika 
typer av manniskors personligheter och satt att 
kommunicera. 


N 



negative testing: Tests aimed at showing that a 
component or system does not work. Negative testing is 
related to the testers' attitude rather than a specific test 
approach or test design technique, e.g. testing with invalid 
input values or exceptions. [After Beizer]. 

negativ testning: Tester med syfte att pavisa att en 
komponent eller ett system inte fungerar. Negativ 
testning ar mer relaterad till testa res attityd an till 
ett specifikt angreppssatt eller testdesignteknik, t.ex. 
testning med ogiltiga indata varden eller testning 
med undantag (eng. exceptions). [Efter Beizer] 

ATT 

neighborhood integration testing: A form of integration 
testing where all of the nodes that connect to a given 
node are the basis for the integration testing. 

grannskapsintegrationstestning: En form av 
integrationstester dar alia knutpunkter (noder) som 
ansluter till en given knutpunkt (nod) ar grunden for 
integrationstestning. 


non-conformity: Non fulfillment of a specified 
requirement. [ISO 9000] 

icke overensstammande: Krav i kravspecifikation 
eller underforstadda krav som inte ar uppfyllda. [ISO 
9000] 

F 

non-functional requirement: A requirement that does not 
relate to functionality, but to attributes such as reliability, 
efficiency, usability, maintainability and portability. 

icke-funktionellt krav: Krav som inte relaterar till 
funktionaliteten i ett program utan till egenskaper 
sasom tillforlitlighet, effektivitet, anvandbarhet, 
underhallbarhet och portabilitet. 
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non-functional test design technique: Procedure to derive 
and/or select test cases for nonfunctional testing based on 
an analysis of the specification of a component or system 

without reference to its internal structure. See also black 
box test design technique. 

testdesignteknik for icke-funktionella egenskaper: 

Procedurfor att skapa och valja testfall for en 
komponent eller ett system utan referens till dess 
interna struktur. Se aven black-box-testdesignteknik. 


non-functional testing: Testing the attributes of a 
component or system that do not relate to functionality, 
e.g. reliability, efficiency, usability, maintainability and 
portability. 

testning av icke-funktionella egenskaper: Testning 
av egenskaper som inte relaterar till funktionalitet. 
Exempel pa sadana egenskaper artillforlitlighet, 
effektivitet, anvandbarhet, underhallbarhet och 
portabilitet. 


N-switch coverage: The percentage of sequences of N+l 
transitions that have been exercised by a test suite. 

[Chow] 

N-switch-tackning: Den procentuella tackningen av 
N+ltillstandsovergangar som har exekverats genom 
ett eller flera testfall ur en testfallssvit. [Chow] 


N-switch testing: A form of state transition testing in 
which test cases are designed to execute all valid 
sequences of N+l transitions. [Chow] See also state 
transition testing. 

N-switch-testning: En variant pa test av 
tillstandsovergangar dar varje testfall ar designad att 
utova alia giltiga sekvenserav N+l overgangar. 

[Chow] Se aven tillstandsbaserad testning. 


n-wise testing: A black box test design technique in which 
test cases are designed to execute all possible discrete 
combinations of any set of n input parameters. 

See also orthogonal array testing, pairwise testing. 

n-wise-testning: En black-box-testdesignteknik dar 
testfall designas for att exekvera alia diskreta 
kombinationer av en uppsattning med n 
ingangsparametrar. Se aven testning baserad pa 
ortogonalitetsmatris, parvis testning. 


0 



off-the-shelf software: A software product that is 
developed for the general market, i.e. for a large number 
of customers, and that is delivered to many customers in 

identical format. 

standardprogramvara: En programvaruprodukt som 
ar utvecklad for den allmanna marknaden, dvs. for 
ett stort antal kunder, och som levereras till manga 

kunder i samma format. Se aven COTS. 

ATM 

open source tool: A software tool that is available to all 
potential users in source code form, usually via the 
internet; its users are permitted, usually under licence, to 
study, change, improve and, at times, to distribute the 

software. 

open source-verktyg: Ett verktyg som artillganglig 
for alia potentiella anvandare i form av kallkod, 
oftast via internet; dess anvandare hartillatelse, 
oftast pa licens, att studera, forandra, forbattra och, 
ibland, for att distribuera programvaran. 

ATA 

operability: The capability of the software product to 
enable the user to operate and control it. [ISO 9126] See 
also usability. 

funktionsduglighet: aven praktisk anvandbarhet, 
driftsduglighet. Programvaruproduktens kapacitet 
att mojliggdra att en anvandare kan anvanda och 
beharska programmet. [ISO 9126] Se anvandbarhet. 
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ATT 

operational acceptance testing: Operational testing in the 
acceptance test phase, typically performed in a 
(simulated) operational environment by operations and/or 
systems administration staff focusing on operational 
aspects, e.g. recoverability, resource-behavior, 
instaliability and technical compliance. See also 
operational testing. 

driftacceptanstestning: Driftstestning i 
acceptanstestfasen, vanligtvis utford i en (simulerad) 
driftsmiljo av drifts- eller administratorspersonal, 
och fokuserad pa driftsaspekter som t.ex., 
aterhamtningsformaga, beteende hos resurser, 

installationsbarhet och teknisk overensstammelse. 

Se aven driftstestning. 


operational environment: Hardware and software 
products installed at users' or customers' sites where the 
component or system under test will be used. The 
software may include operating systems, database 
management systems, and other applications. 

driftsmiljo: En miljo bestaende av hardvaru- och 
programvaruprodukter, regleroch rutinersom ar 
installerade hos kund, eller en miljo dar 
komponenten eller systemet som testas ska 
anvandas senare. Programvaran kan ocksa omfatta 
ope rati vsystem, databashanteringssystem och andra 
applikationer. 

ATT 

ETM 

operational profile: The representation of a distinct set of 
tasks performed by the component or system, possibly 
based on user behavior when interacting with the 
component or system, and their probabilities of 
occurrence. A task is logical rather that physical and can 

be executed over several machines or be executed in non¬ 
contiguous time segments. 

operationell profil: Aven driftsprofil. 

Representationen av en mangd uppgifter utforda av 
en komponent eller system som kan ha baserats pa 
anvandarnas beteende vid interaktion med 
komponenten eller systemet och sannolikheten for 
att dessa intraffar. En uppgift ar snarare logisk an 
fysisk och kan utovas med flera datorer eller utovas i 
diskrettidsrymd. 


operational profile testing: Statistical testing using a 
model of system operations (short duration tasks) and 
their probability of typical use. [Musa] 

modellerad driftsmiljotest: Statistisktestning med 
hjalp av en modell av systemets funktion baserad pa 
en sannolik anvandning av systemet. [Musa] 

ETM 

operational profiling: The process of developing and 
implementing an operational profile. See also operational 
profile. 

operational profiling: TBD 


operational testing: Testing conducted to evaluate a 
component or system in its operational environment. 

[IEEE 610] 

driftstestning: Testning utford i syfte att utvardera 
en komponent eller ett system i dess driftsmiljo. 

[IEEE 610] 


oracle: See test oracle. 

orakel: Se testorakel. 

ATA 

orthogonal array: A 2-dimensional array constructed with 
special mathematical properties, such that choosing any 
two columns in the array provides every pair combination 
of each number in the array. 

ortogonal matris: En 2-dimensionell matris 
konstruerad enligt matematisk egenskaper, sa atttva 
godtyckliga kolumner i matrisen ger alia 
kombinationer av par bestaende av varje siffra i 

matrisen. 
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orthogonal array testing: A systematic way of testing all¬ 
pair combinations of variables using orthogonal arrays. It 
significantly reduces the number of all combinations of 
variables to test all pair combinations. 

See also n-wise testing, pairwise testing. 

testning baserad pa ortogonal matris: Ett 

systematiskt angreppssatt for testning med hjalp av 
alia parkombinationer av variabler harledda fran 
ortogonala matriser. Angreppssattet reducerar 
antalet av alia kombinationertill alia 

parkombinationer att testa. Se aven n-vis testning, 
parvis testning. 


outcome: See result. 

utfall: Se resultat. 


output: A variable (whether stored within a component or 
outside) that is written by a component. 

utdata: En variabel till vilken en komponent skriver 

ett utvarde. 

Kommentar: En variabel kan finnas inuti eller utanfor 

en komponent. 


output domain: The set from which valid output values 

can be selected. See also domain. 

utdatadoman: aven utdatamangd, resultatmangd. 
Mangden av alia mojliga utdata. 


output value: An instance of an output. See also output. 

utdatavarde: aven utvarde. En instans av utdata. 


outsourced testing: Testing performed by people who are 
not co-located with the project team and are not fellow 
employees. 

outsourcad testning: Testning utfors av personer 
som varken ar anstallda kollegor eller 
samlokaliserade med projektgruppen. 


P 



pair programming: A software development approach 
whereby lines of code (production and/or test) of a 
component are written by two programmers sitting at a 
single computer. This implicitly means ongoing real-time 
code reviews are performed. 

parprogrammering: En metod for 
programvaruutveckling dar varje kodrad (i 
produktion och/ellertest) i en komponent ar skriven 
av tva programmerare vid en gemensam dator. 

Detta for att implicit utfora kodgranskning samtidigt 

som kod skrivs. 


pair testing: Two persons, e.g. two testers, a developer 
and a tester, or an end-user and a tester, working together 
to find defects. Typically, they share one computer and 
trade control of it while testing. 

partestning: Tva testare som arbetartillsammans for 
att hitta brister i programvaran. Vanligtvis delar 
dessa pa en dator och turas om att ha kontroll over 
datorn vid testningen. 

ATT 

pairwise integration testing: A form of integration testing 
that targets pairs of components that work together, as 
shown in a call graph. 

parvis integrationstestning: En sorts 
integrationstester som riktarsig mot komponentpar 
som samverkar, enligt en anropsgraf. 

ATA 

pairwise testing: A black box test design technique in 
which test cases are designed to execute all possible 
discrete combinations of each pair of input parameters. 

See also n-wise testing, orthogonal array testing. 

parvis testning: En black-box-testdesignteknik i 
vilken testfall ar designade att exekvera alia mojliga 
diskreta kombinationer av varje par av indata. Se 
aven n-wise testning, testning baserad pa 
ortogonalitetsmatris. 
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EITP 

Pareto analysis: A statistical technique in decision making 

that is used for selection of a limited number of factors 

that produce significant overall effect. In terms of quality 
improvement, a large majority of problems (80%) are 
produced by a few key causes (20%). 

Pareto-analys: En teknikfor beslutsfattande, som 
bygger pa statistiska metoder, vilken anvands for att 
identifiera en begransad mangd faktorer som har en 
stor paverkan pa det slutliga resultatet. En stor 
majoritet av problem (80%) uppstar pa grund av ett 
mindre antal (20%) nyckelorsaker. 


partition testing: See equivalence partitioning. [Beizer] 

testning av delkomponent: Se 

ekvivalensklassfordelning. [Beizer] 


pass: A test is deemed to pass if its actual result matches 
its expected result. 

godkand: aven lyckad. Ett godkant/lyckat test ar ett 

test dar det faktiska resultatet motsvarar det 

forvantade resultatet. 


pass/fail criteria: Decision rules used to determine 
whether a test item (function) or feature has passed or 
failed a test. [IEEE 829] 

godkanda/underkanda kriterier: Beslutsregler for 
att avgora om genomforda tester av ett testelement 
(funktion) eller feature ska godkannas eller 
underkannas. [IEEE 829] 


path: A sequence of events, e.g. executable statements, of 
a component or system from an entry point to an exit 
point. 

vag: En sekvens av exekverbara satser i en 
komponent som borjar vid en startpunkt och avlutas 
vid en slutpunkt. 


path coverage: The percentage of paths that have been 
exercised by a test suite. 100% path coverage implies 

100% LCSAJ coverage. 

vagtackning: Den procentuella delen av vagarsom 
har exekverats genom testfall i en testfallssvit. 100 % 
vagtackning innebar LCSAJ-tackning. 


path sensitizing: Choosing a set of input values to force 
the execution of a given path. 

medvetet vagval: Val av en mangd indata med syfte 
att tvinga (forcera) exekveringen att folja en viss vag. 

ATT 

path testing: A white box test design technique in which 
test cases are designed to execute paths. 

vagtestning: Teknik for att skapa testfall som 
exekverar valda vagar hos en komponent. 

F 

peer review: A review of a software work product by 
colleagues of the producer of the product for the purpose 
of identifying defects and improvements. Examples are 
inspection, technical review and walkthrough. 

kollegial granskning: En granskning av en produkt, 
utford av kolleger till den som tagit fram produkten, i 
syfte att hitta fel och foresla forbattringar. Exempel 
ar inspektion, teknisk granskning och genomgang. 


performance: The degree to which a system or 
component accomplishes its designated functions within 
given constraints regarding processing time and 
throughput rate. [After IEEE 610] See also efficiency. 

prestanda: Formagan hos ett system eller en 
komponent att uppfylla stallda krav pa funktionalitet 
samtidigt som satta begransningarfor 
berakningstideroch systemkapacitet halls. [Efter 

IEEE 610] Se aven effektivitet. 


performance indicator: A high level metric of 
effectiveness and/or efficiency used to guide and control 
progressive development, e.g. lead-time slip for software 
development. [CMMI] 

prestandatal: En abstrakt mattstockfor 

tidseffektivitet och resurseffektivitet som anvands 
som vagledning och kontroll i utvecklingfor 
forbattring av programvara, t.ex. ledtidsglidning vid 
mjukvaruutveckling. [CMMI] 
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performance profiling: The task of analyzing, e.g., 
identifying performance bottlenecks based on generated 
metrics, and tuning the performance of a software 
component or system using tools. 

prestandaprofilering: Uppgiften att analysera, t.ex. 
identifiera flaskhalsar baserat pa genererade 
matetal, och trimma prestandan i en 
programvarukomponent eller ett system med hjalp 
av verktyg. 

F 

ATT 

performance testing: The process of testing to determine 
the performance of a software product. See also efficiency 
testing. 

prestandatestning: Testning vars syfte ar att 
utvardera prestanda hos ett system, en systemdel 
eller en komponent. Testningen avser att 
demonstrera att testobjektet uppfyller specifika 
prestandakrav. Prestandatester omfattar bade last- 
och stresstester. Se aven effektivitetstestning. 

F 

ATT 

performance testing tool: A tool to support performance 
testing that usually has two main facilities: load generation 
and test transaction measurement. Load generation can 

simulate 

either multiple users or high volumes of input data. During 
execution, response time 

measurements are taken from selected transactions and 

these are logged. Performance 

testing tools normally provide reports based on test logs 
and graphs of load against 
response times. 

prestandatestverktyg: Ett verktyg som stodjer 
prestandatestning som vanligtvis har tva 
huvudfaciliteter, lastgenerering och matningav 
testtransaktioner. Lastgenerering kan simulera 
antingen flera anvandare eller stora volymerav 
indata. Svarstider kan matas och loggas fran utvalda 
transaktioner undertestexekvering. Dessa verktyg 
kan normalttillhandahalla rapportersom baseras pa 
testloggar och diagram som visar last jamfort med 

svarstider. 

ATM 

ATA 

phase containment: The percentage of defects that are 
removed in the same phase of the software lifecycle in 
which they were introduced. 

fasinneslutning: Den procentuella andelen av 
defekter som eliminerats i samma fas av livscykeln 
for programvaruutvecklingen dar de uppstod. 


phase test plan: A test plan that typically addresses one 
test phase. See also test plan. 

fastestplan: En testplan for en specifik testniva. Se 
aven testplan. 

ETM 

planning poker: A consensus-based estimation technique, 
mostly used to estimate effort or relative size of user 
stories in agile software development. It is a variation of 
the Wide Band Delphi method using a deck of cards with 
values representing the units in which the team estimates. 
See also agile software development, Wide Band Delphi. 

planning poker: En samsynsbaserad 
estimeringsteknik, som i huvudsak anvands for att 
uppskatta arbetsinsatser eller den relativa storleken 
pa anvandarberattelser vid agil 
programvaruutveckling. Det ar en variant av den 

Wide Band Delphi-metoden som anvander en kortlek 
vars varden representerar de enheter som teamet 
estimerar. Se aven agil programvaruutveckling. Wide 
Band Delphi. 


pointer: A data item that specifies the location of another 
data item; for example, a data item that specifies the 
address of the next employee record to be processed. 

[IEEE 610] 

pekare: Ett dataelement som specificerar platsen for 
ett annat dataelement, t.ex. ett dataelement som 
specificerar adressen till nasta post som ska 
processas. [IEEE 610] 


portability: The ease with which the software product can 

be transferred from one hardware or software 

environment to another. [ISO 9126] 

portabilitet: aven flyttbarhet. Anger hur latt en 
programvaruprodukt kan flyttas fran en hardvaru- 
eller programvarumiljo till en annan. [ISO 9126] 
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F 

ATT 

portability testing: The process of testing to determine 
the portability of a software product. 

portabilitetstestning: Testning av 
portabiliteten/flyttbarheten hos en 
programvaruproduktfran en hardvaru-eller 
programvarumiljo till en annan. 


postcondition: Environmental and state conditions that 

must be fulfilled after the execution of a test or test 
procedure. 

sluttillstand: Tillstand hos miljo och testobjekt som 
maste vara uppfyllda efter exekvering av ett test 
eller en testprocedur. 


post-execution comparison: Comparison of actual and 
expected results, performed after the software has 
finished running. 

jamforelse efter exekvering: aven post- 
exekveringsjamforelse. Jamforelse mellan faktiskt 

resultat och forvantat resultat efter det att 
programvaran har kort fardigt. 


post-project meeting: See retrospective meeting. 

projektutvarderingsmote: Se retrospektivmote. 


precondition: Environmental and state conditions that 
must be fulfilled before the component or system can be 
executed with a particular test or test procedure. 

forutsattning: Miljo- och tillstandsvillkorsom maste 
vara uppfyllda fore exekvering av ett test eller en 
testprocedur. 


predicate: A statement that can evaluate to true or false 
and may be used to determine the control flow of 
subsequent decision logic. See also decision. 

forutsagelse: En programsats som kan resultera i 

sant eller falskt och kan anvandas for att faststalla 

kontrollflodet i darpa foljande beslutslogik. Se aven 
kodvillkor. 


predicted outcome: See expected result. 

forutsagbart resultat: Ett resultat/beteende som ar 
forutsagt/forvantat enligt en komponents 
specifikation under speciella villkor. 


pretest: See intake test. 

fortest: Se oppningstest. 

ATM 

priority: The level of (business) importance assigned to an 
item, e.g. defect. 

prioritet: Graden av betydelse for verksamheten 
som kan tilldelas en produkt (sak), t.ex. fel. 


PRISMA: A systematic approach to risk-based testing that 
employs product risk identification and analysis to create a 
product risk matrix that considers likelihood and impact. 

PRISMA: Ett systematiskt angreppssatt for 
riskbaserad testning som anvander identifiering och 
analys av produktrisker for att skapa en 
produktriskmatris som tar stallning till sannolikhet 

och konsekvens. 

F 

probe effect: The effect on the component or system by 
the measurement instrument when the component or 
system is being measured, e.g. by a performance testing 
tool or monitor. For example performance may be slightly 
worse when performance testing tools are being used. 

probeffekt: Ett matinstruments inverkan pa 
komponenten eller systemet nar komponenten eller 
systemet mats av t.ex. ett prestandatestverktyg eller 
en overvakare. Prestanda kan till exempel bli samre 
nar ett prestandatestverktyg anvands. 


problem: See defect. 

problem: Sefel. 


problem management: See defect management. 

problemadministration: aven defektadministration, 
bristadministration. Se felhantering. 


56 

















\£>t 

\/s 

▼ Ti 


SSTB 


Swedish Software 
Testing Board 



problem report: See defect report. 

problemrapport: aven defektrapport, bristrapport. 

Se felrapport. 


procedure testing: Testing aimed at ensuring that the 
component or system can operate in conjunction with 
new or existing users' business procedures or operational 
procedures. 

procedurtestning: Testningfokuserad pa att 
sakerstalla att en komponent eller ett system kan 
anvandas tillsammans med anvandares nya eller 
existerande affarsprocedurer eller driftsprocedurer. 


process: A set of interrelated activities, which transform 
inputs into outputs. [ISO 12207] 

process: En mangd samverkande aktiviteter som 
transformerar indata till utdata. [ISO 12207] 

EITP 

process assessment: A disciplined evaluation of an 
organization's software processes against a reference 
model, [after ISO 15504] 

processutvardering: En disciplinerad utvardering av 
en organisations programvaruutvecklings-processer 
mot en referensmodell [efter ISO 15504]. 


process cycle test: A black box test design technique in 
which test cases are designed to execute business 
procedures and processes. [TMap] See also procedure 
testing. 

processcykeltest: En black-box-teknikdartestfallen 
ar designade for att exekvera affarsprocedurer och 
processer. [TMap] Se aven procedurtestning. 


process improvement: A program of activities designed to 
improve the performance and maturity of the 
organization's processes, and the result of such a program. 
[CMMI] 

processforbattring: En plan med aktiviteter 
designade for att forbattra effektiviteten och 
mognaden i en organisations processer, avseraven 
resultatet av en sadan plan. [CMMI] 

EITP 

process model: A framework wherein processes of the 
same nature are classified into a overall model, e.g. a test 
improvement model. 

processmodell: Ett ramverk, i vilket processer av 
samma typ klassificeras, t.ex. en 
testforbattringsmodell. 


process reference model: A process model providing a 
generic body of best practices and how to improve in a 
prescribed step-by-step manner. 

processreferensmodell: En processmodell som 
tillhandahaller en generisk samling av best practice 
och forbattringsforslag i form av en steg for steg- 

metod. 

ETM 

process-compliant testing: Testing that follows a set of 
defined processes, e.g., defined by an external party such 
as a standards committee. See also standard-compliant 
testing. 

Processanpassad testning: Testning som foljer en 
uppsattning definierade processer, t.ex. definierade 
av en extern part sasom en 
standardiseringskommitte. Se aven 
standardanpassad testning. 

F 

ATM 

ATA 

ATT 

product risk: A risk directly related to the test object. See 
also risk. 

produktrisk: En risk direkt relaterad till testobjektet, 
uttryckt i sannolikhet och paverkan, for att en 
produkt inte uppfyller stallda krav. Se aven risk. 


Product RISk MAnagement: See PRISMA. 

Product RISk MAnagement: Se PRISMA. 
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EITP 

product-based quality: A view of quality, wherein quality 
is based on a well-defined set of quality attributes. These 
attributes must be measured in an objective and 
quantitative way. Differences in the quality of products of 
the same type can be traced back to the way the specific 
quality attributes have been implemented. [After Garvin] 

See also manufacturingbased quality, quality attribute, 
transcendent-based quality, user-based quality, 
valuebased quality. 

produktbaserad kvalitet: Ett satt att se pa kvalitet 
som innebar att kvaliteten hos en produkt definieras 
via ett antal valdefinierade kvalitetsattribut, vilka ska 
kunna matas objektivt och kvantitativt. 

Kva 1 itetsski 11 nader mellan produkter av samma typ 
kan sparas tillbaka till hurspecifika kvalitetsattribut 
har implementerats. [Efter Garvin] Se aven 
anvandarbaserad kvalitet, tillverkningsbaserad 
kvalitet, upplevd kvalitet och vardebaserad kvalitet. 


production acceptance testing: See operational 
acceptance testing. 

produktionsacceptanstestning: Se 

driftsacceptanstestning. 


program instrumenter: See instrumenter. 

programinstrument: Se instrument. 


program testing: See component testing. 

programtestning: Se komponenttestning. 


project: A project is a unique set of coordinated and 

controlled activities with start and finish dates undertaken 
to achieve an objective conforming to specific 
requirements, including the constraints of time, costand 
resources. [ISO 9000] 

projekt: Ett projekt ar en unik mangd av samordnade 

och kontrollerade aktiviteter dar start- och sluttid for 
aktiviteterna ar underordnade och samstammiga 
med speciella krav, sasom krav pa tid, kostnad och 
resurser. [Efter IS09000] 

EITP 

project retrospective: A structured way to capture lessons 
learned and to create specific action plans for improving 
on the next project or next project phase. 

projektretrospektiv: Ett strukturerat satt att ta 
tillvara erfarenheter och att ska pa specifika 
handlingsplanerfdrattforbattra nasta projekt eller 
projektfas. 

F 

ATM 

project risk: A risk related to management and control of 
the (test) project, e.g. lack of staffing, strict deadlines, 
changing requirements, etc. See also risk. 

projektrisk: En risk som ar relaterad till ledning och 
kontroll av (test) projektet, t.ex., brist pa personal, 
harda deadlines, andrade krav, etc. Se aven risk. 


project test plan: See master test plan. 

projekttestplan: Se overordnad testplan. 


pseudo-random: A series which appears to be random but 
is in fact generated according to some prearranged 

sequence. 

falsk slumpmassighet: En serie data som ar 
genererad som slumpmassig, men ofta med en 
inbyggd sekvens eller ordning. 


Q 



QFD: See Quality Function Deployment. 

QFD: Quality Function Deployment. Se faststallande 
avfunktionskvalitet 


qualification: The process of demonstrating the ability to 
fulfill specified requirements. Note the term 'qualified' is 
used to designate the corresponding status. [ISO 9000] 

kvalifikation: Process for att pavisa kapacitet att 
specificerade krav kan uppfyllas. Notera atttermen 
"kvalificerad" anvands for att ange status for 
kvalifikationen [ISO 9000] 
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F 

quality: The degree to which a component, system or 
process meets specified requirements and/or 
user/customer needs and expectations. [After IEEE 610] 

kvalitet: Till vilken grad en komponent, ett system 
elleren process uppfyller stallda krav och/eller 
anvandares/kunds behov och forvantningar. [Efter 

IEEE 610] 


quality assurance: Part of quality management focused on 
providing confidence that quality requirements will be 
fulfilled. [ISO 9000] 

kvalitetssakring: aven kvalitetsforsakran. Den del av 
kvalitetshanteringen som fokuserar pa atttillgodose 
den konfidens som kravs for att stallda kvalitetskrav 

kan uppfyllas. [ISO 9000] 


quality attribute: A feature or characteristic that affects 
an item's quality. [IEEE 610] 

kvalitetsegenskap: De viktigaste egenskaperna som 
paverkaren produkts kvalitet. [IEEE 610] 


quality characteristic: See quality attribute. 

kvalitetskaraktaristik: Se kvalitetsegenskap. 


quality control: The operational techniques and activities, 
part of quality management, that are focused on fulfilling 
quality requirements, [after ISO 8402] 

Kvalitetskontroll: De operativa teknikeroch 
aktiviteter som ingar som en del i kvalitetshantering 
och som fokuserar pa att uppfylla kvalitetskrav. 

[efter ISO 8402] 


Quality Function Deployment: A method to transform 
user demands into design quality, to deploy the functions 
forming quality, and to deploy methods for achieving the 
design quality into subsystems and component parts, and 
ultimately to specific elements of the manufacturing 
process. [Akao] 

faststallande avfunktionskvalitet: En metod att 

omvandla anvandarkrav till designkvalitet, att 
faststalla de funktioner som utgor kvalitet och att 
faststalla metoderfor att uppna denna 
designkvalitet i delsystem och komponenter, och 
ytterst i specifika element i tillverkningsprocessen. 


quality gate: A special milestone in a project. Quality gates 
are located between those phases of a project strongly 
depending on the outcome of a previous phase. A quality 
gate includes a formal check of the documents of the 
previous phase. 

kvalitetskontrollpunkt: En speciell milstolpe mellan 
tva faser i ett projekt, dar den efterfoljande fasen 
starkt ar beroende av kvaliteten pa resultaten av den 
tidigare fasen. En kvalitetskontrollpunkt inkluderar 
en formell kontroll av dokumenten fran den tidigare 

fasen. 


quality management: Coordinated activities to direct and 
control an organization with regard to quality. Direction 
and control with regard to quality generally includes the 
establishment of the quality policy and quality objectives, 
quality planning, quality control, quality assurance and 
quality improvement. [ISO 9000] 

kvalitetsstyrning: Samordnande aktiviteter for att 
styra och kontrollera en organisation betraffande 
kvalitet. Styrning och kontroll betraffande kvalitet 
generellt, omfattar upprattandet av policy och 
kvalitetsmalsattningar, kvalitetsplanering, 
kvalitetskontroll, kvalitetssakring och 
kvalitetsforbattringar. [ISO 9000] 

ATM 

quality risk: A risk related to a quality attribute. See also 
quality attribute, product risk. 

Kvalitetsrisk: En risk kopplad till kvalitetsattribut. Se 

ocksa kvalitet. 


R 


ETM 

RACI matrix: Responsible, Accountable, Consulted, and 
Informed. 

Engagemangsmatris (RACI-matris): 

Utforandeansvarig (Responsible), Medansvarig 
(Accountable), Konsulterad (Consulted) och 

Informerad (Informed) 
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random testing: A black box test design technique where 
test cases are selected, possibly using a pseudo-random 
generation algorithm, to match an operational profile. This 
technique can be used for testing non-functional 
attributes such as reliability and performance. 

slumpbaserade tester: En black-box-teknik dar 
testfallen ar valda, mojligen med anvandning av 
pseudoslumpmassiga genereringsalgoritmer, for att 
generera mojliga operationella scenarion. Denna 
teknik kan anvandas for icke funktionella attribut 

som t.ex. tillfdrlitlighet och prestanda. 

EITP 

Rational Unified Process: A proprietary adaptable 
iterative software development process framework 
consisting of four project lifecycle phases: inception, 
elaboration, construction and transition. 

Rational Unified Process: Ett patenterattillampbart 
iterativt utvecklingsprocessramverk som bestar av 
fyra projektlivscykelfaser: forberedelse, etablering, 
konstruktion och overlamning. 

ETM 

reactive testing: Testing that dynamically responds to the 
actual system under test and test results being obtained. 
Typically reactive testing has a reduced planning cycle and 
the design and implementation test phases are not carried 
out until the test object is received. 

Reaktiv testning: Testning som dynamiskt svarar pa 
det aktuella systemet som testas och de testresultat 
som erhallits. Typisk reaktiv testning har en 
reducerad planeringscykel och testfaserna design 
och implementation utfors inte forran testobjektet 
erhallits. 

ATT 

record/playback tool: See capture/playback tool. 

registrerings- och uppspelningsverktyg: Se in- och 

uppspelningsverktyg. 


recorder: See scribe. 

registrator: Se sekreterare. 


recoverability: The capability of the software product to 
re-establish a specified level of performance and recover 
the data directly affected in case of failure. [ISO 9126] See 
also reliability. 

aterhamtningsformaga: Progra mva ru prod uktens 
kapacitet att ateruppta en specificerad niva av 
prestanda och att aterfa direkt paverkade data nar 
fel intraffat. [ISO 9126] Se aven tillfdrlitlighet. 

ATT 

recoverability testing: The process of testing to determine 
the recoverability of a software product. See also 
reliability testing. 

aterhamtningsbarhetstestning: Testprocess som 
syftartill att sakerstalla aterhamtningsbarheten hos 
en programvaruprodukt. Se aven 
tillfdrlitlighetstestning. 


recovery testing: See recoverability testing. 

aterhamtningstestning: Se 

aterhamtningsbarhetstestning. 

F 

regression testing: Testing of a previously tested program 
following modification to ensure that defects have not 
been introduced or uncovered in unchanged areas of the 
software, as a result of the changes made. It is performed 
when the software or its environment is changed. 

regressionstestning: Testning av ett program dar 
testfallen exekveras i syfte att sakerstalla att fel inte 
blivit introducerade eller blottlagda som ett resultat 
av utforda andringar eller tillagg i programmet. 
Regressionstestning utfors nar programvaran eller 
dess miljd har andrats. Jamfor omtestning. 

ETM 

regression-averse testing: Testing using various 
techniques to manage the risk of regression, e.g., by 
designing re-usable testware and by extensive automation 
of testing at one or more test levels. 

regressionshammande testning: Testning med olika 
teknikerforatt hantera riskerna med regression, 
t.ex. genom att designa ateranvandbartestvara och 
genom omfattande testautomatisering pa en eller 
flera testnivaer. 


regulation testing: See compliance testing. 

regleringstestning: Se testning for typgodkannande. 
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release note: A document identifying test items, their 
configuration, current status and other delivery 
information delivered by development to testing, and 
possibly other stakeholders, at the start of a test execution 
phase. [After IEEE 829] 

leveransdokument: Ett dokument som identifierar 

testenheter, konfiguration, nuvarande status och 
annan information levererad till test fran utvecklare i 

borjan av en testfas. [IEEE 829] 


reliability: The ability of the software product to perform 
its required functions under stated conditions for a 
specified period of time, or for a specified number of 
operations. [ISO 9126] 

tillforlitlighet: Kapaciteten hos en 
programvaruprodukt att utfora specificerad 
funktionalitet under vissa forutsattningar for en viss 
tidsperiod eller med ett visst antal anvandningar av 
programvaran. [ISO 9126] 

ATT 

reliability growth model: A model that shows the growth 
in reliability overtime during continuous testing of a 
component or system as a result of the removal of defects 
that result in reliability failures. 

Reliability Growth Model: En modell visande den 
okning i tillforlitlighet under en tidsperiod dar 
kontinuerlig testning av komponenter eller system 
och rattning av fel som visar sig i 
tillforlitlighetsfelsymptom. 

F 

ATT 

reliability testing: The process of testing to determine the 
reliability of a software product. 

tillforlitlighetstestning: Processen att utfora testning 
i syfte att bestamma tillforlitligheten hos en 
programvaruprodukt. 

ATT 

replaceability: The capability of the software product to 
be used in place of another specified software product for 
the same purpose in the same environment. [ISO 9126] 

See also portability. 

ersattningsbarhet: Kapaciteten hos 
programvaruprodukten att anvandas istallet for en 
annan specificerad programvaruprodukt for samma 
andamal och i samma miljo. [ISO 9126] Se aven 
portabilitet. 

F 

requirement: A condition or capability needed by a user to 
solve a problem or achieve an objective that must be met 
or possessed by a system or system component to satisfy 
a contract, standard, specification, or other formally 
imposed document. [After IEEE 610] 

krav: Ett villkor eller en egenskap som en bestallare 
kraver for att en losning pa ett problem eller ett mal 
for ett system eller delsystem ska uppfylla ett 
kontrakt, en standard, en specifikation eller andra 
formella tvingande dokument. [Efter IEEE 610] 

F 

requirements management tool: A tool that supports the 
recording of requirements, requirements attributes (e.g. 
priority, knowledge responsible) and annotation, and 
facilitates traceability through layers of requirements and 
requirements change management. Some requirements 
management tools also provide facilities for static analysis, 
such as consistency checking and violations to pre-defined 
requirements rules. 

kravhanteringsverktyg: Verktyg som stodjer 
registrering av krav, kravattribut och noteringar samt 
underlattar sparbarhet genom nivaer av krav och 
kravhantering och kravandringar. Vissa 
kravhanteringsverktyg har ocksa stod for statisk 
analys sasom kontroll av overensstammande och 
overtradelser av fordefinierade krav eller regler. 


requirements phase: The period of time in the software 
lifecycle during which the requirements for a software 
product are defined and documented. [IEEE 610] 

kravfasen: Den tidsperiod i programvarans livscykel 
da kraven for programvaruprodukten definieras och 
dokumenteras. [IEEE 610] 
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ATA 

requirements-based testing: An approach to testing in 
which test cases are designed based on test objectives and 
test conditions derived from requirements, e.g. tests that 
exercise specific functions or probe non-functional 
attributes such as reliability or usability. 

kravbaserad test: Utveckling avtestfall med 
utgangspunktfran krav pa systemet eller 
komponenten. 


resource utilization: The capability of the software 
product to use appropriate amounts and types of 
resources, for example the amounts of main and 
secondary memory used by the program and the sizes of 
required temporary or overflow files, when the software 
performs its function under stated conditions. [After ISO 
9126] See also efficiency. 

resursanvandning: Egenskapen hos 
programvaruprodukten attanvanda bestamtantal 
och bestamd typ av resurser, t.ex. det primar- och 
sekundarminne som anvands av programmet och 
storleken pa temporara filer, nar programvaran utfor 
sin funktion under bestamda forutsattningar. [ISO 
9126] Se aven effektivitet. 

ATT 

resource utilization testing: The process of testing to 
determine the resource-utilization of a software product. 
See also efficiency testing. 

resursanvandningstestning: Testprocessen for att 
sakerstalla resursanvandningen for en 
programvaruprodukt. Se aven effektivitetstestning. 


result: The consequence/outcome of the execution of a 
test. It includes outputs to screens, changes to data, 
reports, and communication messages sent out. See also 
actual result, expected result. 

resultat: Konsekvensen eller utfalletfran 

exekveringen av etttest. Se aven faktiskt resultat 
(eng. actual result), forvantat resultat (eng. expected 
result). 


resumption criteria: The criteria used to restart all or a 
portion of the testing activities that were suspended 
previously. 

aterstartskriterier: Testaktivitetersom maste 

repeteras nartestningen aterupptas efter ett 

avbrott. 


resumption requirements: The defined set of testing 
activities that must be repeated when testing is re-started 
after a suspension. [After IEEE 829] 

aterstartskrav: En uppsattning testaktivitetersom 
maste repeteras nar testning aterupptas efter ett 
avbrott. [Efter IEEE 829], 

F 

re-testing: Testing that runs test cases that failed the last 
time they were run, in order to verify the success of 

corrective actions. 

omtestning: Testning som innebar omexekvering av 
de testfall som tidigare misslyckats for att man pa sa 
satt ska verifiera att andringsatgarder har lyckats. 

Jmf. regressionstestning. 

Kommentar: Omexekvering med ett testfall som 
tidigare felat, for att avgora om rattning verkligen ar 
korrigerad, dvs. testning att en felrattning verkligen 
hartagit bort den kanda avvikelsen. 
Regressionstestning kontrollerar dessutom att 
rattningen inte har medfort andra och oonskade 
sidoeffekter. 

EITP 

retrospective meeting: A meeting at the end of a project 
during which the project team members evaluate the 
project and learn lessons that can be applied to the next 
project. 

retrospektivmote: Ett mote i slutet av ett projekt dar 
projektets medlemmar utvarderar projektet och 

lardom noteras for att anvandas i kommande 

projekt. 
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F 

ATM 

review: An evaluation of a product or project status to 
ascertain discrepancies from planned results and to 
recommend improvements. Examples include 
management review, informal review, technical review, 
inspection, and walkthrough. [After IEEE 1028] 

granskning: En utvardering av en produkt eller 
systemstatus med syfte att upptacka avvikelserfran 
planerat resultat och for att rekommendera 
atgarder. Exempel kan vara informella granskningar, 
inspektioner och genomgangar. [Efter IEEE 1028] 

ATM 

review plan: A document describing the approach, 

resources and schedule of intended review activities. It 

identifies, amongst others: documents and code to be 
reviewed, review types to be used, participants, as well as 
entry and exit criteria to be applied in case of formal 
reviewes, and the rationale for their choice. It is a record 
of the review planning process. 

activities. 

granskningsplan: Ett dokument som beskriver 
angreppssatt, resurser och schema for planerade 
granskningsaktiviteter. Det identifierar bland annat 
dokument och kod som ska granskas, 
granskningstyper som ska anvandas, deltagare, start 
och avslutskriteria som ska appliceras vid formella 
granskningar, och motivet for valet. Det ar en 
dokumentation av granskningsplaneringsprocessen. 

F 

review tool: A tool that provides support to the review 
process. Typical features include review planning and 
tracking support, communication support, collaborative 
reviews and a repository for collecting and reporting of 

metrics. 

granskningsverktyg: Verktyg som stodjer 
granskningsprocessen. Typiska funktioner ar 
granskningsplanering och sparning, stod for 
kommunikation, stod for granskningssamarbete och 
en databas for insamling och rapportering av 

matvarden. 

F 

ATM 

reviewer: The person involved in the review that identifies 
and describes anomalies in the product or project under 
review. Reviewers can be chosen to represent different 
viewpoints and roles in the review process. 

granskare: En person som deltar i en granskning och 

som ska identifiera och beskriva 
avvikelser/felaktigheter i produkten eller projektet 
som granskas. Granskare kan utses for att 
representera olika kompetensomraden och roller i 
granskningsprocessen. 

F 

ATM 

risk: A factor that could result in future negative 
consequences; usually expressed as impact and likelihood. 

risk: En faktorsom kan resultera i en framtida 

negativ konsekvens oftast uttryckt i sannolikhet och 
paverkan. 

ATM 

ATA 

ATT 

risk analysis: The process of assessing identified project or 
product risks to determine their level of risk, typically by 
estimating their impact and probability of occurrence 
(likelihood) 

riskanalys: En process for att analysera identifierade 
projekt- och produktriskerforattfaststalla 
sannolikheten for att de intraffar samt den paverkan 

som fas om sa sker. 

ATM 

ATT 

risk assessment: The process of identifying and 
subsequently analyzing the identified project or product 
risk to determine its level of risk, typically by assigning 
likelihood and impact ratings. 

See also product risk, project risk, risk, risk impact, risk 
level, risk likelihood. 

riskbedomning: Processen att identifiera och 
darefter bedoma en given projekt- eller produktrisk 
for att avgora dess riskniva, typiskt genom att tilldela 
grader av sannolikhet och konsekvens. Se aven 
produktrisk, projektrisk, risk, riskkonsekvens, 
riskniva, risksannolikhet. 


risk category: See risk type. 

riskkategori: Se risktyp. 

ATM 

ATA 

ATT 

risk control: The process through which decisions are 
reached and protective measures are implemented for 
reducing risks to, or maintaining risks within, specified 

levels. 

riskkontroll: En process dar besluttas och 
skyddande atgarder implementeras for att reducera 
riskerna till (eller behalla riskerna pa) en viss niva. 
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ATM 

ATA 

risk identification: The process of identifying risks using 
techniques such as brainstorming, checklists and failure 
history. 

riskidentifiering: Processen for att identifiera risker 
genom att anvanda tekniker som ideklackning, 

checklistor och felhistorik. 


risk impact: The damage that will be caused if the risk 

become an actual outcome or event. 

riskkonsekvens: Skadan som kommer att uppsta ifall 
risken blir ett verkligt resultat eller handelse. 

ATM 

ATA 

ATT 

risk level: The importance of a risk as defined by its 
characteristics impact and likelihood. The level of risk can 
be used to determine the intensity of testing to be 
performed. A risk level can be expressed either 
qualitatively (e.g. high, medium, low) or quantitatively. 

riskniva: Viktigheten for en risk definierad genom 
egenskaperna paverkan och sannolikhet hos risken. 
Risknivan kan anvandas for att avgora hur mycket 
testning som ska utforas. En riskniva kan uttryckas 
kvalitativt (t.ex. hog, medium, lag) eller kvantitativt. 


risk likelihood: The estimated probability that a risk will 

become an actual outcome or event. 

risksannolikhet: Den uppskattade sannolikheten att 
en risk kommer att bli ett verkligt resultat eller 

handelse. 

ATM 

ATA 

risk management: Systematic application of procedures 
and practices to the tasks of identifying, analyzing, 
prioritizing, and controlling risk. 

riskhantering: Ett systematiskt tillvagagangssatt i 
syfte att identifiera, analysera, rangordna, definiera 
atgarderfor att atgarda risker, hanskjuta risker, 
minimera risker eller avfarda risker. 

ATM 

ATA 

ATT 

risk mitigation: See risk control. 

riskminskning: Se riskkontroll. 


risk type: A set of risks grouped by one or more common 
factors such as a quality attribute, cause, location, or 
potential effect of risk;. A specific set of product risk types 
is related to the type of testing that can mitigate (control) 
that risk type. For example the risk of userinteractions 
being misunderstood can be mitigated by usability testing. 

risktyp: En uppsattning risker grupperade efter en 
eller flera gemensamma faktorer sasom 
kvalitetsattribut, orsak, lokalisering eller potentiella 
konsekvenserav riskerna. En speciell kategori av 
produktrisktyper ar relaterade till den typ av testning 
som kan minska (kontrollera) dessa risker. Till 
exempel kan risken att anvandarinteraktion 
missforstas minskas genom anvandbarhetstestning. 

F 

ATM 

ATT 

risk-based testing: An approach to testing to reduce the 
level of product risks and inform stakeholders of their 
status, starting in the initial stages of a project. It involves 
the identification of product risks and the use of risk levels 
to guide the test process 

riskbaserad testning: Ett angreppssatt for testning 
som reducerar nivan for produktrisker och 
informerarintressenterom riskernas status, med 
borjan i initiala faserna i projektet. Det innefattar 
identifiering av produktrisker samt anvandning av 
risknivaer for att styra test processen. 

Kommentar: Att utfora riskkontroll genom testning 
mojliggdr aterkoppling som ger information om 
kvarvarande risker genom att mata effektiviteten i 
borttagandet av allvarliga fel och effektiviteten i 
katastrofplaner. 
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ATT 

robustness: The degree to which a component or system 
can function correctly in the presence of invalid inputs or 
stressful environmental conditions. [IEEE 610] See also 
error-tolerance, fault-tolerance. 

robusthet: Den niva pa vilken en komponent eller ett 
system kan fungera ratt med ogiltiga indata eller 
stressad miljo. [IEEE 610] Se aven feltolerans. 

F 

robustness testing: Testing to determine the robustness 
of the software product. 

robusthetstestning: Testning for att faststalla 
robustheten hos en programvaruprodukt. 

ATM 

root cause: A source of a defect such that if it is removed, 
the occurrence of the defect type is decreased or 
removed. [CMMI] 

grundorsak: En underliggande faktor som orsakar att 
specifikation och implementation inte stammer 

overens. 

ATA 

root cause analysis: An analysis technique aimed at 
identifying the root causes of defects. By directing 
corrective measures at root causes, it is hoped that the 
likelihood of defect recurrence will be minimized. 

analys av grundorsak: En analysteknik som fokuserar 
pa att identifiera grundorsaken for ett fel. Genom att 
koncentrera matningarfor korrigeringar hoppas man 
pa att minimera sannolikheten for aterkomst av 

felet. 

EITP 

RUP: See Rational Unified Process. 

RUP: Se Rational Unified Process. 


S 


ETM 

S.M.A.R.T. goal methodology: A methodology whereby 
objectives are defined very 

specifically rather than generically. SMART is an acronym 

derived from the attributes of 

the objective to be defined: Specific, Measurable, 

Attainable, Relevant and Timely. 

S.M.A.R.T. metodik for mal: En metod dar malen 
definieras mycket specifikt snarare an generellt. 
SMART ar en akronym som harleds fran attributen 
for det mal som skall definieras: Specifikt, Matbart, 
Accepterat, Realistiskt, Tidsatt. 


safety: The capability of the software product to achieve 
acceptable levels of risk of harm to people, business, 
software, property or the environment in a specified 
context of use. [ISO 9126] 

sakerhet: Formagan hos ett system att uppna 
acceptabla risknivaerforatt manniskor, verksamhet, 
programvara, egendom och miljo inte ska komma till 
skada vid en speciell anvandning. [ISO 9126] 


safety critical system: A system whose failure or 
malfunction may result in death or serious injury to 
people, or loss or severe damage to equipment, or 
environmental harm. 

sakerhetskritiska system: Ett system vars 
felsymptom eller haveri kan leda till dodsfall, orsaka 
skador pa personer, utrustning eller miljon. 


safety testing: Testing to determine the safety of a 
software product. 

sakerhetstestning: Testning for att avgora 
sakerheten hos en programvaruprodukt. 


sanity test: See smoke test. 

omddmestest: Se roktest. 


scalability: The capability of the software product to be 
upgraded to accommodate increased loads. [After 

Gerrard] 

skalbarhet: Kapaciteten hos en programvara att bli 
uppgraderad till en anpassad okad belastning. 


scalability testing: Testing to determine the scalability of 
the software product. 

skalbar testning: Test som utfors for att faststalla 
skalbarhet hos programvaran. 
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scenario testing: See use case testing. 

scenariobaserad test: Se anvandningsfallsbaserad 
testning. 


scorecard: A representation of summarized performance 
measurements representing progress towards the 
implementation of long-term goals. A scorecard provides 
static measurements of performance over or at the end of 
a defined interval. See also balanced scorecard, 

dashboard. 

styrkort: En representation av sammanstallda 
matningar som representerar arbetet med att uppna 
langsiktiga mal. Ett styrkort innehaller matningar av 
prestanda over tiden eller vid slutet av ett bestamt 
tidsintervall. Se aven balanserat styrkort, dashboard 
och corporate dashboard. 

F 

scribe: The person who records each defect mentioned 
and any suggestions for process improvement during a 
review meeting, on a logging form. The scribe should 
ensure that the logging form is readable and 

understandable. 

sekreterare: En person som ansvararfor att i ett 
loggningsformular dokumentera varje defekt som 
patalats och varje forslag till processforbattringar 
under ett granskningsmote. Sekreteraren maste 
sakerstalla att loggningsformularet ar lasbart och gar 
attforsta. 


scripted testing: Test execution carried out by following a 
previously documented sequence of tests. 

skripttestning: Testexekvering utfors genom att folja 

dokumenterade testsekvenser. 

F 

scripting language: A programming language in which 
executable test scripts are written, used by a test 
execution tool (e.g. a capture/playback tool). 

skriptsprak: Ett programmeringssprak dar 
exekverbara testskript skrivs. Ofta anvands ett 
testexekveringsverktyg (t.ex. in- och 
uppspelningsverktyg). 

EITP 

SCRUM: An iterative incremental framework for managing 
projects commonly used with agile software development. 
See also agile software development. 

SCRUM: Ett iterativt, inkrementellt ramverk for 
hantering av projekt, vanligen anvant i agila 
programvaruutvecklingsmetoder. Se aven agil 
programvaruutveckling. 


security: Attributes of software products that bear on its 
ability to prevent unauthorized access, whether accidental 
or deliberate, to programs and data. [ISO 9126] See also 
functionality. 

informationssakerhet: Egenskaper hos en 
programvaruprodukt med avseende pa dessformaga 
att forhindra otillaten anvandning eller atkomst till 
program eller data. [ISO 9126] Se aven 
funktionalitet. 

F 

ATT 

security testing: Testing to determine the security of the 
software product. See also functionality testing. 

informationssakerhetstestning: Testning av hur ett 

system klarar sin specificerade informationssakerhet. 
Se aven funktionalitetstestning. 


security testing tool: A tool that provides support for 
testing security characteristics and vulnerabilities. 

testverktyg for informationssakerhet: Ett verktyg 

som tillhandahaller stod for test av sakerhet och 

sarbarhet. 

F 

security tool: A tool that supports operational security. 

verktyg for informationssakerhet: Ett verktyg som 
stoder operativ sakerhet, t.ex. en brandvagg. 


serviceability testing: See maintainability testing. 

servicebarhetstestning: Se 

underhallbarhetstestning. 
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session-based test management: A method for measuring 
and managing session-based testing, e.g. exploratory 
testing. 

sessionsbaserad teststyrning: En metod for att mata 
och styra sessionsbaserad testning, t.ex. utforskande 
testning. 


session-based testing: An approach to testing in which 
test activities are planned as uninterrupted sessions of 
test design and execution, often used in conjunction with 
exploratory testing. 

sessionsbaserad testning: En testmetodik i vilken 
testaktiviteter planeras i sessioner som bestir av 
samtidig testdesign och testexekvering och dar 
sessionerna inte far avbrytas. Sessionsbaserad 
testning anvands ofta vid utforskande testning. 

ATM 

severity: The degree of impact that a defect has on the 
development or operation of a component or system. 

[After IEEE 610] 

allvarlighet: Den grad av paverkan som ettfel har pa 
utveckling eller drift av en komponent eller system. 
[Efter IEEE 610] 

ETM 

Shewhart chart: See control chart. 

Shewhart-diagram: Se kontrolldiagram. 

ATT 

short-circuiting: A programming language/interpreter 
technique for evaluating compound conditions in which a 
condition on one side of a logical operator may not be 
evaluated if the condition on the other side is sufficient to 

determine the final outcome. 

kortslutning: En teknik for 

programmeringssprak/programtolkar att utvardera 
villkorssammansattningar dar ett villkor pa ena sidan 
av en logisk operator inte kan utvarderas om 
villkoret pa andra sidan ar tillrackligt for att faststalla 
det slutliga resultatet. 


simulation: The representation of selected behavioral 
characteristics of one physical or abstract system by 
another system. [ISO 2382/1] 

simulering: Atergivning av valda beteendemonster 
och egenskaper hos ett fysiskt eller abstrakt system 
med hjalp av ett annat system. 


simulator: A device, computer program or system used 
during testing, which behaves or operates like a given 
system when provided with a set of controlled inputs. 

[After IEEE 610, D0178b] See also emulator. 

simulator: Utrustning, program eller system som 
anvands vid testning och beter sig likadant som ett 
givet system eller en komponent, da det ges en 
mangd av kontrollerade invarden. [Efter IEEE 610, 
D0178b] Se aven emulator. 

Kommentar: Notera att egenskaper som 
tidsberoende faktorer oftast inte gar att testa med 
denna metod. 


site acceptance testing: Acceptance testing by 
users/customers at their site, to determine whether or not 
a component or system satisfies the user/customer needs 
and fits within the business processes, normally including 
hardware as well as software. 

acceptanstestning i driftsmiljo: Acceptanstestning i 
driftsmiljo utfors av anvandare/kund i deras miljo. 
Anvandare/kund avgorom komponenten eller 
system fyller deras behov och passar in i deras 
affarsmodell. Normalt tar man hansyn till bade 
hardvara och programvara. 


smoke test: A subset of all defined/planned test cases that 
cover the main functionality of a component or system, to 
ascertaining that the most crucial functions of a program 
work, but not bothering with finer details. A daily build 
and smoke test is among industry best practices. See also 

intake test. 

roktest: Ett urval av alia definierade/planerade 
testfall som tacker den huvudsakliga funktionaliteten 
hos en komponent eller ett system, som racker for 
att fon/issa sig om att de mest kritiska funktionerna 
av programmet fungerar utan att fordjupa sig i 
detaljer. Inom industrin ar dagligt byggande och 
roktest "best practice". Se aven oppningstest. 
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software: Computer programs, procedures, and possibly 
associated documentation and data pertaining to the 
operation of a computer system. [IEEE 610] 

programvara: Ett antal styrinstruktioner, d.v.s. 
kodsatser som fungerar som en helhet som 
tillsammans med data och maskinvara utgorett 
system. [IEEE 610] 


software attack: See attack. 

programvaruattack: Se attack. 


Software Failure Mode and Effect Analysis (SFMEA): See 

Failure Mode and Effect Analysis (FMEA). 

SFMEA (Software Failure Mode and Effect Analysis): 

Se FMEA. 


Software Failure Mode, Effects, and Criticality Analysis 
(SFMECA): See Failure Mode,Effects, and Criticality 

Analysis (FMECA). 

SFMECA (Software Failure Mode, Effects, and 
Criticality Analysis): Se FMECA. 


Software Fault Tree Analysis (SFTA): See Fault Tree 

Analysis (FTA). 

SFTA (Software Fault Tree Analysis): Se FTA (Fault 

Tree Analysis). 


software feature: See feature. 

programfiness: Se finess. 


software integrity level: The degree to which software 
complies or must comply with a set of stakeholder- 
selected software and/or software-based system 
characteristics (e.g., software complexity, risk assessment, 
safety level, security level, desired performance, reliability, 
or cost) which are defined to reflect the importance of the 
software to its stakeholders. 

integritetsniva for programvara: Den grad som 
programvaran uppfyller eller maste uppfylla en 
uppsattning av intressenter utvald programvara 
och/eller programvaruvarubaserade 
systemegenskaper (t.ex. programvarukomplexitet, 
riskbedomning, skydds- och sakerhetsniva, forvantat 
beteende, tillforlitlighet, eller kostnad) vilka anges 
for att reflektera over programvarans betydelse for 

dess intressenter. 

EITP 

software lifecycle: The period of time that begins when a 
software product is conceived and ends when the 
software is no longer available for use. The software 
lifecycle typically includes a concept phase, requirements 
phase, design phase, implementation phase, test phase, 
installation and checkout phase, operation and 
maintenance phase, and sometimes, retirement phase. 

Note these phases may overlap or be performed 
iteratively. 

livscykel for programvara: Den tidsperiod som 
borjar nar en ide for programvaran fods och slutar 
nar programvaran inte langre finns tillganglig for 
anvandning. 

Kommentar: En programvaras livscykel innehaller 
vanligtvis en idefas, kravfas, designfas, 
implementeringsfas, testfas, installations och 
utcheckningsfas, drift- och underhallfas och ibland 
en indragning av programvaran. Notera att dessa 
faser kan overlappa eller utforas iterativt. 

EITP 

Software Process Improvement: A program of activities 
designed to improve the performance and maturity of the 
organization's software processes and the results of such a 
program. [After CMMI] 

Software Process Improvement: Ett 

aktivitetsprogram framtaget for att forbattra 
prestandan och mognaden i en organisations 
programvaruprocesser samt resultaten av att ett 
sadant program anvants. [Efter CMMI] 


software product characteristic: See quality attribute. 

produktkaraktaristik for programvara: Se 

kvalitetsegenskap. 
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software quality: The totality of functionality and features 
of a software product that bear on its ability to satisfy 
stated or implied needs. [After ISO 9126] See also quality. 

programvarukvalitet: Den totala funktionaliteten 
och egenskaperna hos en programvaruprodukt med 
syfte att tillfredsstalla faststallda och underforstadda 
krav. [Efter ISO 9126] Se aven kvalitet. 


software quality characteristic: See quality attribute. 

kvalitetskaraktaristik for programvara: Se 

kvalitetsegenskap. 


software test incident: See incident. 

testincident i programvara: Se avvikelse. 


software test incident report: See incident report. 

testincidentrapport for programvara: Se 

avvikelserapport. 

ATA 

Software Usability Measurement Inventory (SUMt): A 

questionnaire-based usability test technique for 
measuring software quality from the end user's point of 
view. [Veenendaal04] 

SUMI (Software Usability Measurment Inventory): 

En fragebaserad metod for anvandbarhetstest, 
vilken mater programvarans kvalitet fran ett 
slutanvandarperspektiv. [Veenendaal] 


source statement: See statement. 

kallkodsats: Se kodsats. 


specification: A document that specifies, ideally in a 
complete, precise and verifiable manner, the 
requirements, design, behavior, or other characteristics of 
a component or system, and, often, the procedures for 
determining whether these provisions have been satisfied. 
[After IEEE 610] 

specifikation: Ett dokument som specificerar 
(idealiskt pa ett komplett, precist och verifierbart 
satt) krav, design, beteende och egenskaper hos en 
komponent eller ett system och. Ofta ingar 
procedurer som anvands for att avgora om dessa 
mal har blivit uppfyllda. [Efter IEEE 610] 

ATA 

specification-based technique: See black box test design 
technique. 

specifikationsbaserad teknik: Se black-box- 
testdesignteknik. 


specification-based test design technique: See black box 
test design technique. 

specifikationsbaserad testdesignteknik: Se black- 
box-testdesignteknik. 


specification-based testing: See black box testing. 

specifikationsbaserad testning: Se black-box- 
testning. 


specified input: An input for which the specification 
predicts a result. 

specificerade indata: Invarden till vilka en 
specifikation beskriverforvantat utvarde. 

EITP 

SPI: See Software Process Improvement. 

SPI: Se Software Process Improvement. 

ATT 

stability: The capability of the software product to avoid 
unexpected effects from modifications in the software. 

[ISO 9126] See also maintainability. 

stabilitet: Kapaciteten hosen programvaruprodukt 
att inte paverkas negativt av modifieringar i 
programvaran. [ISO 9126] Se aven underhallbarhet. 

EITP 

staged representation: A model structure wherein 
attaining the goals of a set of process areas establishes a 
maturity level; each level builds a foundation for 
subsequent levels. [CMMI] 

stegrepresentation: En modellstruktur man genom 
att uppna malen inom ett antal processomraden 
etableraren mognadsniva, varje niva bygger upp en 
bas for de efterfoljande nivaerna. [CMMI] 
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EITP 

standard: Formal, possibly mandatory, set of 
requirements developed and used to prescribe consistent 
approaches to the way of working or to provide guidelines 
(e.g., ISO/IEC standards, IEEE standards, and 
organizational standards). [After CMMI] 

standard: En mangd formella, tvingande alternativt 
radgorande, krav framtagna for att sakerstalla ett 
konsekvent arbetssatt. (t.ex. ISO/IEC standarder, 

IEEE standarder och organisatoriska standarder). 
[EfterCMMI] 


standard software: See off-the-shelf software. 

standardprogramvara 

ETM 

standard-compliant testing: Testing that complies to a set 
of requirements defined by a standard, e.g., an industry 
testing standard or a standard for testing safety-critical 
systems. See also process-compliant testing. 

standardanpassad testning: Testning som uppfyller 
en uppsattning krav som faststallts av en standard, 
t.ex. en branschspecifik standard for test eller en 
standard rorande testning av sakerhetskritiska 
system. Se aven processanpassad testning. 


standards testing: See compliance testing. 

standardtestning: Se testning for typgodkannande. 


state diagram: A diagram that depicts the states that a 
component or system can assume, and shows the events 
or circumstances that cause and/or result from a change 
from one state to another. [IEEE 610] 

tillstandsdiagram: Ett diagram som skildrar de 
tillstand som komponenten eller systemet kan anta 
och visar de handelser och omstandigheter som 
orsakar och/eller ar resultatet av forandringar fran 
ett tillstand till ett annat. [IEEE 610] 


state table: A grid showing the resulting transitions for 
each state combined with each possible event, showing 
both valid and invalid transitions. 

tillstandstabell: En tabell som for varje tillstand och 
forvarje handelse visar tillatna och otillatna 
overgangar i ett system eller en komponent. 


state transition: A transition between two states of a 

component or system. 

tillstandsovergang: En overgang mellan tva tillstand i 
ett system eller en komponent. 

F 

ATA 

state transition testing: A black box test design technique 
in which test cases are designed to execute valid and 
invalid state transitions. See also N-switch testing. 

tillstandsbaserad testning: En testteknik som 
innebar att man gor testfall avsedda att testa en eller 
flera tillstandsovergangar. Se aven test av 
tillstandsovergangssekvenser av langd N+l.. 

Kommentar: Anvandbar teknik pa alia nivaer av 
testning. Ett tillstandsdiagram bestar av tillstand och 
tillstandsovergangar. Denna modell kan skapas 
direktfran koden eller pa ett mera schematiskt 
tillstand, t.ex. ett anvandningsfall. 


statement: An entity in a programming language, which is 
typically the smallest indivisible unit of execution. 

kodsats: aven kodrad, kodblock. Den minsta 
exekverbara enheten i programsprak. 

F 

statement coverage: The percentage of executable 
statements that have been exercised by a test suite. 

kodsatstackning: aven tackning av satser eller 

kodrader. Den del av exekverbara kodsatser som 
blivit exekverade av en testsvit, angivet i procent. 

ATT 

statement testing: A white box test design technique in 
which test cases are designed to execute statements. 

kodsatstestning: aven testning av kodsatser eller 
kodrader. En white-box-testdesignteknik dar testfall 
ar framtagna for att exekvera kodsatser 
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F 

ATT 

static analysis: Analysis of software development artifacts, 
e.g. requirements or code, carried out without execution 
of these software development artifacts. Static analysis is 
usually carried out by means of a supporting tool. 

statisk analys: Analys av programvaruartefakter, 
t.ex. krav eller programvarukod, utan att dessa 
artefakter exekveras. Vanligtvis utfors statisk analys 
med hjalp av verktyg. 

F 

static analysis tool: See static analyzer. 

statiskt analysverktyg: Se verktyg for statisk analys. 

ATT 

static analyzer: A tool that carries out static analysis. 

verktyg for statisk analys: Ett verktyg som utfor 
statisk analys. 


static code analysis: Analysis of source code carried out 
without execution of that software. 

statisk kodanalys: Analys av kallkod utford utan att 
programvaran exekveras. 


static code analyzer: A tool that carries out static code 
analysis. The tool checks source code, for certain 
properties such as conformance to coding standards, 
quality metrics or data flow anomalies. 

verktyg for statisk kodanalys: En kategori av verktyg 
for statisk analys som enbart riktar in sig pa analys av 
kallkod. Verktyget analyserar koden med avseende 
pa t.ex. tillampningsgrad av kodstandarder, 

kvalitetsmatt eller dataflodesavvikelser. 

F 

static testing: Testing of a software development artifact, 
e.g., requirements, design or code, without execution of 
these artifacts, e.g., reviews or static analysis. 

statisk testning: Testning av en 
programvaruartefakt, t.ex. krav, design, eller kod 
utan att exekvera dessa artefakter, t.ex. 
granskningar eller statisk analys. 


statistical testing: A test design technique in which a 
model of the statistical distribution of the input is used to 
construct representative test cases. See also operational 
profile testing. 

statistikbaserad test: En testdesignteknik dar man 
anvander sig av statistisk spridning av invarden for 
att konstruera representativa testfall. Se aven 
modellerad driftsmiljotest. 


status accounting: An element of configuration 
management, consisting of the recording and reporting of 
information needed to manage a configuration effectively. 
This information includes a listing of the approved 
configuration identification, the status of proposed 
changes to the configuration, and the implementation 
status of the approved changes. [IEEE 610] 

statusredovisning: Ett moment i 
konfigurationshantering som bestar av att 
dokumentera och rapportera information som ar 
nodvandigfor att hantera en konfiguration pa ett 
effektivt satt. Informationen innehaller en lista over 

godkanda identifierade konfigurationer, status pa 
foreslagna andringar av konfigurationen och status 
pa implementation av godkanda andringar. [IEEE 

610] 

ATM 

EITP 

STEP: See Systematic Test and Evaluation Process. 

STEP: Se Systematic Test and Evaluation Process. 


storage: See resource utilization. 

lagring: Se resursanvandning. 


storage testing: See resource utilization testing. 

lagringstestning: Se resursanvandningstestning. 

F 

stress testing: A type of performance testing conducted to 
evaluate a system or component at or beyond the limits of 
its anticipated or specified workloads, or with reduced 
availability of resources such as access to memory or 
servers. [After IEEE 610] See also performance testing, 
load testing. 

stresstestning: En typ av prestandatest som utfors 
for att utvardera ett system eller en komponent pa 
eller over gransen for dess forvantade eller 
specificerade arbetsbelastning, eller med reducerad 
tillganglighet till minne eller servrar. [Efter IEEE 610] 

Se aven prestandatest, lasttest. 


71 
















\£>t 

\/s 

▼ Ti 


SSTB 


Swedish Software 
Testing Board 


F 

stress testing tool: A tool that supports stress testing. 

verktyg for stresstestning: Ett verktyg (program) 
som stodjer stresstestning. Se aven stresstestning. 


structural coverage: Coverage measures based on the 
internal structure of a component or system. 

strukturtackning: aven strukturell kodtackning. 
Matning av kodtackning som baseras pa den interna 
strukturen hos koden eller systemet. 


structural test design technique: See white-box test 
design technique. 

testdesignteknik for strukturella tester: Se white- 
box-testdesignteknik. 

F 

structural testing: See white-box testing. 

strukturell testning: Se white-box-testning. 

ATT 

structure-based technique: See white-box test design 
technique. 

strukturbaserad teknik: Se white-box- 

testdesignteknik. 


structure-based test design technique: See white-box test 
design technique. 

strukturbaserad testdesignteknik: Se white-box- 
testdesignteknik. 

F 

structure-based testing: See white-box testing. 

strukturbaserad testning: Se white-box-testning. 


structured walkthrough: See walkthrough. 

strukturerad granskningsgenomgang: Se 

genomgang. 

F 

stub: A skeletal or special-purpose implementation of a 
software component, used to develop or test a 
component that calls or is otherwise dependent on it. It 
replaces a called component. [After IEEE 610] 

stubbe: En speciellt utvecklad programkod, eller 
programskelett, vars syfte ar underlatta testning av 
en programdel eller komponent, som ar beroende av 
eller anroparstubben. 

Kommentar: Anvands ofta for att ersatta en modul 

som annu inte utvecklats, for att man ska kunna 

testa andra delar. 


subpath: A sequence of executable statements within a 
component. 

delvag: En sekvens av exekverbara satser inom en 
komponent. 


suitability: The capability of the software product to 
provide an appropriate set of functions for specified tasks 
and user objectives. [ISO 9126] See also functionality. 

andamalsenlighet: Programvaruproduktens 
kapacitet att tillhandahalla andamalsenlig 
funktionalitet for specificerade uppgifter och 
anvandarmal. [ISO 9126] Se aven funktionalitet. 

ATA 

suitability testing: The process of testing to determine the 
suitability of a software product 

testning av andamalsenlighet: Den testaktivitet som 
ska sakerstalla andamalsenligheten hos en 
programvaruprodukt. 

ATA 

SUMI: See Software Usability Measurement Inventory. 

SUMI: Se Software Usability Measurement 

Inventory. 


suspension criteria: The criteria used to (temporarily) stop 
all or a portion of the testing activities on the test items. 
[After IEEE 829] 

avbrottskriterier: Kriterier som anvands for att 

(tillfalligt) stoppa alia eller delar var testaktiviteterna 
fortestobjektet. 
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syntax testing: A black box test design technique in which 
test cases are designed based upon the definition of the 
input domain and/or output domain. 

syntaxtestning: En black-box-testdesignteknik for att 
skapa testfall for en komponent eller ett system som 
baseras pa definitionen av indatadomanen och/eller 

utdatadomanen. 


system: A collection of components organized to 
accomplish a specific function or set of functions. [IEEE 

610] 

system: En samling komponenter organiserade pa 
ett satt sa att en specifik funktionalitet eller mangd 
avfunktionalitet uppnas. [IEEE 610] 


system integration testing: Testing the integration of 
systems and packages; testing interfaces to external 
organizations (e.g. Electronic Data Interchange, Internet). 

systemintegrationstestning: Testning vid 
integrationen av ett system. Vid integrationstestning 
testas granssnitten mellan systemet och dess miljo. 


system of systems: Multiple heterogeneous, distributed 
systems that are embedded in networks at multiple levels 
and in multiple interconnected domains, addressing large- 
scale inter-disciplinary common problems and purposes, 
usually without a common management structure. 

system av system: Heterogena multipla 
distribuerade system som ar inbyggda pa flera olika 
nivaer i natverk och over flera ihopkopplade 
domaner, som adresserar storskaliga problem och 
syften interdisciplinart utan att ha ett gemensamt 
kont roll system. 

F 

system testing: The process of testing an integrated 
system to verify that it meets specified requirements. 
[Hetzel] 

systemtestning: En testprocess dar ett integrerat 
system testas i syfte att verifiera att systemet 
motsvararstallda krav. [Hetzel] 


system under test: See test object. 

system under test: Se testobjekt. 

ATM 

EITP 

Systematic Test and Evaluation Process: A structured 
testing methodology, also used as a content-based model 
for improving the testing process. Systematic Test and 
Evaluation Process (STEP) does not require that 
improvements occur in a specific order. See also content- 
based model. 

Systematic Test and Evaluation Process: En 

strukturerad testmetodik som aven kan anvandas 

som en innehallsbaserad modell for 

testprocessforbattring. Systematic Test and 

Evaluation Process (STEP) kraver inte att 
forbattringar genomfors i nagon specifik ordning. Se 

aven innehallsbaserad modell. 


T 



TDD: See Test Driven Development. 

TDD: Se testdriven utveckling. 

F 

ATM 

technical review: A peer group discussion activity that 
focuses on achieving consensus on the technical approach 
to be taken. [Gilb and Graham], [IEEE 1028] See also peer 

review. 

tekniskgranskning: En kollegial gruppdiskussion dar 
fokus ar att uppna samstammighet om vilka tekniska 
angreppssatt som ska anvandas. [Gilb och Graham, 

IEEE 1028] Se aven kollegial granskning. 


test: A set of one or more test cases. [IEEE 829] 

test: En mangd av ett eller flera testfall. [IEEE 829] 


test analysis: The process of analyzing the test basis and 
defining test objectives. 

testanalys: Processen att analysera testbasen och 

faststalla testmal. 
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F 

ATM 

test approach: The implementation of the test strategy for 
a specific project. It typically includes the decisions made 
that follow based on the (test) project's goal and the risk 
assessment carried out, starting points regarding the test 
process, the test design techniques to be applied, exit 
criteria and test types to be performed 

angreppssatt for test: Implementering av 
teststrategi for ett specifikt projekt. Vanligen baseras 
detta angreppssatt pa projektmalen och systemets 
identifierade risker, dar man anpassartestprocess, 
valjertestomraden och testteknikersamttestfall och 
beslutar om vilka slutkriterier som galler. 

ETM 

test architect: (1) A person who provides guidance and 
strategic direction for a test organization and for its 
relationship with other disciplines. (2) A person who 
defines the way testing is structured for a given system, 
including topics such as test tools and test data 
management. 

testarkitekt: (1) En person som tillhandahaller 
vagledning och strategisk ledning for en 
testorganisation och for dess relation med andra 
discipliner. (2) En person som definierar sattet som 
testning ar strukturerad for ett givet system, 
inklusive omraden som testverktyg och 
testdatahantering. 


test automation: The use of software to perform or 
support test activities, e.g. test management, test design, 
test execution and results checking. 

testautomatisering: Anvandandetav programvara 
for att kontrollera exekvering av test, jamforelse 
mellan forvantat resultat och verkligt resultat, 
konfigurering av testmiljo och andra testkontroll- 
och testrapporteringsfunktionaliteter. 

F 

test basis: All documents from which the requirements of 
a component or system can be inferred. The 

documentation on which the test cases are based. If a 
document can be amended only by way of formal 
amendment procedure, then the test basis is called a 
frozen test basis. [After TMap] 

testbas: All dokumentation fran vilken man kan 

harleda kravforen komponent eller ett system, dvs. 
den dokumentation som testfall baseras pa. Om ett 
dokument endast kan laggas till genom en formell 
process sa kallas testbasen for en frusen testbas. 
[EfterTMap] 


test bed: See test environment. 

testbadd: aven testbank. Se testmiljo. 

F 

ATM 

test case: A set of input values, execution preconditions, 
expected results and execution postconditions, developed 
for a particular objective or test condition, such as to 
exercise a particular program path or to verify compliance 
with a specific requirement. [After IEEE 610] 

testfall: En samling indata, forutsattningar infor 
exekvering, forvantat resultat och sluttillstand efter 
exekvering, som arframtagna for ett specifikt objekt 
ellertestvillkor. Anvandsforattverifiera uppfyllelsen 
av ett specifikt krav hos en utpekad programdel. 

[Efter IEEE 610] 


test case design technique: See test design technique. 

testfallsdesignteknik: Se testdesignteknik. 

F 

test case specification: A document specifying a set of test 
cases (objective, inputs, test actions, expected results, and 
execution preconditions) for a test item. [After IEEE 829] 

See also test specification. 

testfallsspecifikation: Ett dokument som specificerar 
en mangd av testfall (mal, indata, testaktiviteter, 
forvantat resultat och exekveringsforutsattningar) 
for ett testobjekt. Se aven testspecifikation. 


test case suite: See test suite. 

testfallssvit: Se testsvit. 

ATA 

test charter: A statement of test objectives, and possibly 

test ideas about how to test. Test charters are used in 
exploratory testing. See also exploratory testing. 

testcharter: En redogorelse (lista) fortestmal och 
mojliga testideer. Testlistor anvands bl.a. vid 
utforskande testning. Se aven utforskande testning. 
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ATM 

test closure: During the test closure phase of a test 
process data is collected from completed activities to 
consolidate experience, testware, facts and numbers. The 
test closure phase consists of finalizing and archiving the 
testware and evaluating the test process, including 
preparation of a test evaluation report. See also test 

process. 

testavslut: Aktiviteter utforda for att samla in data 

fran tidigare avslutade testaktiviteter, fakta och 

matvarden. Testavslutsfasen bestar av avslutande 
och arkivering av testvara, utvardering av 
testprocessen samt framtagande av en 
utvarderingsrapport. Se aven testprocess. 

F 

test comparator: A test tool to perform automated test 
comparison of actual results with expected results. 

testkomparator: Ett testverktyg som jamfor det 
verkliga resultatet (som har producerats av objektet 
som testats) med detforvantade resultatfor det 
specifika testfallet. 


test comparison: The process of identifying differences 
between the actual results produced by the component or 
system under test and the expected results for a test. Test 
comparison can be performed during test execution 
(dynamic comparison) or after test execution. 

testjamforelse: Processen att identifiera skillnader 
mellan det verkliga resultatet (som har producerats 
av en komponent eller en programvara som testas) 
och detforvantade resultatet. Testjamforelse kan 
utforas under testexekvering (dynamisk jamforelse) 
eller efte rat. 


test completion criteria: See exit criteria. 

testavslutskriterier: Se avslutskriterier. 

F 

ATM 

test condition: An item or event of a component or 
system that could be verified by one or more test cases, 
e.g. a function, transaction, feature, quality attribute, or 

structural element. 

testvillkor: Ett objekt eller en handelse hos en 
komponent eller ett system som kan verifieras med 
ett eller flera testfall. Ett objekt eller en handelse kan 
i detta fall vara en funktion, en transaktion, ett 
kvalitetsattribut eller en strukturell programvarudel. 

F 

ATM 

ATA 

test control: A test management task that deals with 
developing and applying a set of what was planned. See 
also test management. 

teststyrning: En testledningsaktivitet som hanterar 
utveckling och tillampning av vad som planerats. Se 
aven testledning. 

F 

test coverage: See coverage. 

testtackning: Se tackningsgrad. 


test cycle: Execution of the test process against a single 
identifiable release of the test object. 

testcykel: Genomforande av en testprocess pa en 
enskild identifierbar utgava av etttestobjekt. 

F 

test data: Data that exists (for example, in a database) 
before a test is executed, and that affects or is affected by 
the component or system under test. 

testdata: Datavarden som existerar (till exempel i en 
databas) fore exekverandet av ett test och som 
paverkar eller paverkas av den testade 
komponenten eller det testade systemet. 

Kommentar: Observera att vissa (ISTQB) definierar 

testdata som de indata som kravs for att kora ett 
testfall, medan andra (IEEE) inkluderar aven 
testresultat i begreppet. 


test data management: The process of analyzing test data 
requirements, designing test data structures, creating and 
maintaining test data. 

testdatahantering: Processen att analysera krav pa 
testdata, designa testdatastrukturer, ska pa och 

underhalla testdata. 
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F 

ATA 

test data preparation tool: A type of test tool that enables 
data to be selected from existing databases or created, 
generated, manipulated and edited for use in testing. 

verktyg for forberedelse av testdata: Verktyg som 
interagerar med databaser, filer eller 
dataoverforingar for att forbereda testdata for 
testexekvering. 


test deliverable: Any test (work) product that must be 
delivered to someone other than the test (work) product's 
author. See also deliverable. 

testleverabel: Varje test[arbets]produkt som ska 
levereras till ytterligare nagon utover 
test[arbets]produktensforfattare. Se aven leverabel. 

F 

ATM 

ATA 

test design: (1) See test design specification. 

(2) The process of transforming general test objectives 
into tangible test conditions and test cases. 

testdesign: (1) Se testdesignspecifikation. 

(2) Process for overforing fran generella 
testmalsattningartill konkreta testvillkor och testfall. 


test design specification: A document specifying the test 
conditions (coverage items) for a test item, the detailed 
test approach and identifying the associated high level test 
cases. [After IEEE 829] See also test specification. 

testdesignspecifikation: Ett dokument som 
specificerar testvillkor for ett testelement, detaljerat 
angreppssatt och tillhorande hognivatestfall. [Efter 
IEEE 829] Se aven testspecifikation. 

F 

test design technique: Procedure used to derive and/or 

select test cases. 

testdesignteknik: En metod att harleda, valja 
och/eller specificera testfall. 

F 

ATA 

test design tool: A tool that supports the test design 
activity by generating test inputs from a specification that 
may be held in a CASE tool repository, e.g. requirements 
management tool, from specified test conditions held in 
the tool itself, or from code. 

testdesignverktyg: Ett verktyg som stodjer 
testdesignaktiviteten genom att generera indata fran 
en specifikation, som kan finnas i en CASE-databas, 
t.ex. kravhanteringsverktyg. Data kan ocksa 
genereras fran speciella testvillkor som finns i sjalva 
verktyget. 

ATM 

test director: A senior manager who manages test 
managers. See also test manager. 

testchef: En senior testledare som ledertestledare. 

Se aven testledare. 

F 

ETM 

test driven development: A way of developing software 
where the test cases are developed, and often automated, 
before the software is developed to run those test cases 

testdriven utveckling: Ett satt att utveckla 
programvara dar testfall tas fram, och ofta 
automatiseras, in nan program varan som dessa 
testfall ska exekveras mot hartagits fram. 


test driver: See driver. 

testdrivrutin: Se drivrutin. 

F 

test environment: An environment containing hardware, 
instrumentation, simulators, software tools, and other 
support elements needed to conduct a test. [After IEEE 

610] 

testmiljo: En miljo innehallande hardvara, 
instrumentation, simulatorer, programvaruverktyg 
och andra hjalpmedel som kravs for att utfora 
testning. [After IEEE 610] 

ATM 

test estimation: The calculated approximation of a result 
related to various aspects of testing (e.g. effort spent, 
completion date, costs involved, number of test cases, 
etc.) which is usable even if input data may be incomplete, 
uncertain, or noisy. 

testuppskattning: En beraknad uppskattning av 
testrelaterade resultat (t.ex. tidsatgang, slutdatum, 
kostnader, antal testfall etc.) som ar anvandbar aven 
om indata ar ofullstandigt, ovisst eller oklart. 
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test evaluation report: A document produced at the end 
of the test process summarizing all testing activities and 
results. It also contains an evaluation of the test process 

and lessons learned. 

testutvarderingsrapport: Ett dokument som 
produceras i slutet av testprocessen for att summera 

alia testaktiviteter och resultat. Det innehaller ocksa 

utvardering av testprocessen och 
erfarenhetsreflektioner. 

F 

ATM 

ATA 

test execution: The process of running a test on the 
component or system under test, producing actual 
result(s). 

testexekvering: aven testgenomforande. Processen 
att exekvera en testprocedur mot en komponent 
eller ett system som ar under test for att producera 

ettfaktiskt resultat. 


test execution automation: The use of software, e.g. 
capture/playback tools, to control the execution of tests, 
the comparison of actual results to expected results, the 
setting up of test preconditions, and other test control and 
reporting functions. 

automatiserad testexekvering: Att kontrollera 
testexekvering samt jamfora testutfall med forvantat 
resultat, satta upp forutsattning, annan teststyrning 
och rapportfunktioner med hjalp av en programvara. 


test execution phase: The period of time in a software 
development lifecycle during which the components of a 
software product are executed, and the software product 
is evaluated to determine whether or not requirements 
have been satisfied. [IEEE 610] 

testexekveringsfas: Den tidsperiod i en 
programvaras utvecklingslivscykel da komponenter 
inom en programvaruprodukt exekveras och 
programvaruprodukten utvarderas for att avgora om 
kraven ar ratt implementerade. [IEEE610] 

F 

test execution schedule: The test procedures are included 

in the test execution schedule in their context and in the 

order in which they are to be executed. 

testexekveringsschema: Testpracedurer ingaende i 
testexekveringsschemat i ratt sammanhang och i den 
ordning de skall exekveras. 


test execution technique: The method used to perform 
the actual test execution, either manual or automated. 

testexekveringsteknik: Metod som anvandsfor 
testexekvering, antingen manuell eller 

automatiserad. 

F 

ATA 

ATT 

test execution tool: A type of test tool that is able to 
execute other software using an automated test script, 
e.g. capture/playback. [Fewster and Graham] 

testexekveringsverktyg: En typ av testverktyg som 
utfor exekvering av annan programvara genom 
automatiserade testskript, t.ex. in- och 
uppspelningsverktyg. [Fewster och Graham] 


test fail: See fail. 

testfel: Se fel. 


test generator: See test data preparation tool. 

testfallsgenerator: Se verktyg for forberedelse av 

testdata. 

F 

test harness: A test environment comprised of stubs and 

drivers needed to execute a test. 

testexekveringsplattform: aven testharness. En 
testmiljo som bestar av de stubbar och drivrutiner 
som behovs for att genomfora en test. 

Kommentar: En testexekveringsplattform kan 
mdjliggora testning av en del av ett system genom 
att simulera miljon i vilken testet skall exekvera. En 
testexekveringsplattform kan ocksa anvandas for att 
instrumentera systemet och rapportera testresultat. 
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ATM 

ATA 

test implementation: The process of developing and 
prioritizing test procedures, creating test data and, 
optionally, preparing test harnesses and writing 
automated test scripts. 

testimplementation: Process for att utveckla och 
prioritera testprocedurer, skapa testdata och, 
valfritt, att forbereda for testexekveringsplattform 
och skriva automatiserade testskript. 

EITP 

test improvement plan: A plan for achieving 
organizational test process improvement objectives based 
on a thorough understanding of the current strengths and 
weaknesses of the organization's test processes and test 
process assets. [After CMMI] 

testforbattringsplan: En plan for att uppna 
organisatoriska testprocessforbattringar baserad pa 
en djup forstaelse for organisationens styrkor och 
svagheter samt dess testprocesser och 
testprocesstillgangar. [efter CMMI] 


test incident: See incident. 

testincident: Se avvikelse. 


test incident report: See incident report. 

testincidentrapport: Se avvikelserapport. 


test infrastructure: The organizational artifacts needed to 
perform testing, consisting of test environments, test 
tools, office environment and procedures. 

testinfrastruktur: Organisatoriska artefaktersom ar 
nodvandiga for att utfora tester och bestir av 
testmiljo, testverktyg, kontorsmiljo och processer. 


test input: The data received from an external source by 
the test object during test execution. The external source 
can be hardware, software or human. 

testindata: Data fran en extern kalla in till 

testobjektet som anvands under testgenomforande. 
Den externa kalian kan vara hardvara, programvara 
elleranvandare. 


test item: The individual element to be tested. There 

usually is one test object and many test items. See also 
test object. 

testelement: Ett individuellt element for test. 

Normalt ar det ett testobjekt och flera testelement. 

Se aven testobjekt. 


test item transmittal report: See release note. 

leveransrapport for testelement: Se 

leveransdokument. 

F 

test leader: See test manager. 

testkoordinator: Se testledare. 

F 

ATM 

test level: A group of test activities that are organized and 
managed together. A test level is linked to the 
responsibilities in a project. Examples of test levels are 
component test, integration test, system test and 
acceptance test. [After TMap] 

testniva: En grupp av testaktiviteter som organiseras 
och hanteras tillsammans. En testniva ar kopplad till 
ansvarsfordelningen i ett projekt. Exempel pa 
testnivaerar komponenttest, integrationstest, 
systemtest och acceptanstest. [Efter TMap] 

F 

ATM 

test log: A chronological record of relevant details about 
the execution of tests. [IEEE 829] 

testlogg: En kronologiskt ordnad logg bestaende av 
detaljinformation rorande en testexekvering. [IEEE 

829] 


test logging: The process of recording information about 
tests executed into a test log. 

testloggning: Processen att registrera information 
om exekverade tester i en testlogg. 

ATM 

test management: The planning, estimating, monitoring 
and control of test activities, typically carried out by a test 

manager. 

testledning: Planering, uppskattning, overvakning 
och regiering av testaktiviteter. Testledning utfors 
typiskt av en testledare. Aven strukturering och 
atkomst av testfall kan raknas till testledning. 
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F 

ATT 

test management tool: A tool that provides support to the 
test management and control part of a test process. It 
often has several capabilities, such as testware 
management, scheduling of tests, the logging of results, 
progress tracking, incident management and test 
reporting. 

testledningsverktyg: Verktyg som stodjer 
testledningen. Exempel pa funktioner i 
testledningsverktyg ar: stod for oberoende 
versionshantering, granssnittfor 
testexekveringsverktyg, stod for sparbarhet av test, 
loggning av testresultat osv. 

F 

test manager: The person responsible for project 
management of testing activities and resources, and 
evaluation of a test object. The individual who directs, 
controls, administers, plans and regulates the evaluation 
of a test object. 

testledare: Den person som ansvarar for att 
projektleda testaktiviteter och resurser samt 
utvardera testobjekt. Personen leder, reglerar, 
administrerar, planerar och styr utvarderingen av 
testobjekt. 

ATM 

EITP 

Test Maturity Model integration: A five level staged 
framework for test process improvement, related to the 
Capability Maturity Model Integration (CMMI), that 
describes the key elements of an effective test process. 

Test Maturity Model Integration (TMMi): Ettfem- 
stegs ramverk for forbattring av testprocess 
relaterad till CMMI (Capability Maturity Model 
Integration), som beskriver de viktigaste delarna i en 
effektiv testprocess. 

ETM 

test mission: The purpose of testing for an organization, 
often documented as part of the test policy. See also test 
policy. 

testuppdrag: Syftet med test for en organisation, 
ofta dokumenterad som en del avtestpolicyn. Se 
aven testpolicy. 

F 

ATM 

ATA 

test monitoring: A test management task that deals with 
the activities related to periodically checking the status of 
a test project. Reports are prepared that compare the 
actuals to that which was planned. See also test 
management. 

testovervakning: aven testbevakning. En 
testledningsaktivitet som ger aterkoppling till och 
synlighet for testaktiviteter. Information av intresse 

kan inhamtas manuellt eller automatiskt och 
anvandas for att mata avslutskriterier (t.ex. 
tackning). Informationen kan ocksa anvandas for att 
faststalla projektets framatskridande. Exempel pa 
vanlig testovervakningsinformation ar: 

• avklarad andel testforberedelse 

• antal exekverade testfall 

• subjektiva reflektionerfran testare 

• testkostnader 


test object: The component or system to be tested. See 

also test item. 

testobjekt: Den komponent eller det system som 

testas. Se aven testelement. 

Kommentar: Vid test avtva eller flera objekt anvands 
aven benamningen testelement. 

F 

test objective: A reason or purpose for designing and 
executing a test. 

testmalsattning: Ett syfte eller en anledning som 
liggertill grund for utveckling och exekvering av 

testfall. 
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test oracle: A source to determine expected results to 
compare with the actual result of the software under test. 
An oracle may be the existing system (for a benchmark), 
other software, a user manual, or an individual's 
specialized knowledge, but should not be the code. [After 
Adrion] 

testorakel: En kalla som anvands for att jamfora 

forvantat resultat med aktuellt resultat fran 

programvaran som testas. Ett orakel kan vara ett 
befintligt system (for benchmarktestning), en 
kvalitetssakrad anvandarmanual, annan 
programvara eller en persons speciella kunskaper, 
men far inte vara sjalva koden. [Efter Adrion] 


test outcome: See result. 

testutfall: Se resultat. 


test pass: See pass. 

godkand test: Se godkand. 


test performance indicator: A high level metric of 
effectiveness and/or efficiency used to guide and control 
progressive test development, e.g. Defect Detection 
Percentage (DDP). 

indikatorfortestprestanda: Ett matetal pa hog niva 
som mater effektivitet och anvands for att vagleda 
och reglera progressiv testutveckling, t.ex. Defect 
Detection Percentage (DDP). Se aven DDP. 


test phase: A distinct set of test activities collected into a 
manageable phase of a project, e.g. the execution 
activities of a test level. [After Gerrard] 

testfas: En bestamd uppsattning avtestaktiviteter 
som ar samlade inom en hanterbar del av projektet, 
t.ex. exekveringsaktiviteterfor en testniva. [Efter 
Gerrard] 

F 

ATM 

test plan: A document describing the scope, approach, 

resources and schedule of intended test activities. It 

identifies amongst others test items, the features to be 
tested, the testing tasks, who will do each task, degree of 
tester independence, the test environment, the test 
design techniques and entry and exit criteria to be used, 
and the rationale for their choice, and any risks requiring 
contingency planning. It is a record of the test planning 
process. [After IEEE 829] 

testplan: Ett dokument som beskriver malsattning, 
angreppssatt, resurser och tidplaner for de avsedda 

testaktiviteterna. Dar identifiers bland annat 
testelement, funktioner som ska testas, testuppdrag 
som ska goras, vem som ska utfora testuppdragen, 
nivan pa testoberoende, testmiljo, 
testdesigntekniker, mattekniker, forutsattningaroch 
sluttillstand som ska anvandas med logisk grund, 
samt risker som kraver atgardsplaner. Testplanen ar 
en nedteckning av planeringsprocessen. [efter IEEE 
829] 

ATM 

ATA 

test planning: The activity of establishing or updating a 
test plan. 

testplanering: Attta fram eller uppdatera en 
testplan. 


Test Point Analysis (TPA): A formula based test estimation 
method based on function point analysis. [TMap] 

TPA (Test Point Analysis): aven testmangdsanalys. 

En formelstyrd testberakningsmetod som baserarsig 
pa funktionsgradsanalys (FPA). [TMap] 

F 

ATM 

EITP 

ETM 

test policy: A high level document describing the 
principles, approach and major objectives of the 
organization regarding testing. 

testpolicy: Ett hogniva dokument som beskriver 
principer, angreppssatt och storre mal for 
organisationen nar det galler testning. 

F 

ATM 

test procedure: See test procedure specification. 

testprocedur: aven testinstruktion. Se 
testprocedurspecifikation. 
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F 

ATM 

test procedure specification: A document specifying a 
sequence of actions for the execution of a test. Also 
known as test script or manual test script. [After IEEE 829] 
See also test specification. 

testprocedurspecifikation: Ett dokument med 
detaljerade instruktioner som beskriver hur 
exekveringen skall ga till for ett eller flera testfall. 

Kallas aven for testskript eller manuellt testskript. 
[Efter IEEE 829] Se aven testspecifikation. 


test process: The fundamental test process comprises test 
planning and control, test analysis and design, test 
implementation and execution, evaluating exit criteria and 
reporting, and test closure activities. 

testprocess: Den grundlaggande testprocessen 
omfattar testplanering och kontroll, testanalys och - 
design, testimplementation och -exekvering, 
utvardering av avslutskriterier och rapportering, 
samt aktiviteter for testavslut. 

EITP 

Test Process Group: A collection of (test) specialists who 
facilitate the definition, maintenance, and improvement of 
the test processes used by an organization. [After CMMI] 

testprocessgrupp: En samling [test]specialistersom 
mojliggdr skapande, underhall och forbattringar at 
de testprocesser som anvands i en organisation. 

[efter CMMI] 

EITP 

test process improvement manifesto: A statement that 

echoes the agile manifesto, and 

defines values for improving the testing process. The 

values are: 

- flexibility over detailed processes 

- best practices over templates 

- deployment orientation over process orientation 

- peer reviews over quality assurance (departments) 

- business driven over model driven. [Veenendaal08] 

manifestet for testprocessforbattring: Ett uttryck 
inspirerat av det agila manifestet, vilket beskriver de 
varden som liggertill grund for forbattringar av 
testprocessen. Dessa varden ar: 

- flexibilitet framfor detaljerade processer, 

- best practice framfor mallar, 

- produktorientering framfor processorientering, 

- granskning framfor kvalitetssakring(savdelningar), 

- affarsdriven framfor modelldriven. [Veenendaal08] 

EITP 

test process improver: A person implementing 
improvements in the test process based on a test 
improvement plan. 

testprocessforbattrare: Person som genomfor 
forbattringar av testprocessen, baserat pa en 
testforbattringsplan. 


test progress report: A document summarizing testing 
activities and results, produced at regular intervals, to 
report progress of testing activities against a baseline 
(such as the original test plan) and to communicate risks 
and alternatives requiring a decision to management. 

testprogressrapport: Ett dokument dar man 
summerar testaktiviteter och resultat med syfte att 
rapportera framsteg for testaktiviteter jamfort med 
en faststalld konfiguration (sasom den ursprungliga 
testplanen) och for att informera ledningen om 

risker och alternativ som kraver beslut. 


test record: See test log. 

testprotokoll: Se testlogg. 


test recording: See test logging. 

testregistrering: Se testloggning. 


test report: See test summary report and test progress 
report. 

testrapport: Se slutlig testrapport och rapport for 
testprogress 


test reporting: Collecting and analyzing data from testing 
activities and subsequently consolidating the data in a 
report to inform stakeholders. 

See also test process. 

testrapportering: Insamling och analys av data fran 

testaktiviteter och darefter sammanstallande av 
denna data i en rapport som information till 

intressenter. 

Se aven testprocess. 
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test reproducibility: An attribute of a test indicating 
whether the same results are produced each time the test 

is executed. 

testreproducerbarhet: En testegenskap dar samma 
resultat nas varje gang testen exekveras. 


test requirement: See test condition. 

testkrav: Se testvillkor. 


test result: See result. 

testresultat: Se resultat. 


test rig: See test environment. 

testuppsattning: Se testmiljo. 


test run: Execution of a test on a specific version of the 
test object. 

testkorning: Exekvering av en delmangd av en test 
pa en specifik version av testobjektet. 


test run log: See test log. 

testkorningslogg: Se testlogg. 


test scenario: See test procedure specification. 

testscenario: Se testprocedurspecifikation. 


test schedule: A list of activities, tasks or events of the test 
process, identifying their intended start and finish dates 
and/or times, and interdependencies. 

testschema: En lista av aktiviteter, uppgiftereller 
handelserforen testprocess, dar man identifierar 
mojliga startdatum och starttider och/eller 
slutdatum och sluttider, och beroenden mellan 

dessa. 

F 

ATM 

test script: Commonly used to refer to a test procedure 
specification, especially an automated one. 

testskript: aven testkod. Syftar vanligen pa den 
automatiserade testproceduren som anvands med 
en testexekveringsplattform. 


test session: An uninterrupted period of time spent in 
executing tests. In exploratory testing, each test session is 
focused on a charter, but testers can also explore new 
opportunities or issues during a session. The tester creates 
and executes test cases on the fly and records their 
progress. See also exploratory testing. 

testsession: En fortlopande tidsperiod utan avbrott 

dar tiden anvands for att utova test. 1 utforskande 
testning ar varje testsession koncentrerattill en lista, 
men testare kan ocksa utforska nya mojligheteroch 
problem vid en session. Testaren skapar och utovar 
testfall nar dessa behovs och loggar resultatet. Se 
aven utforskande testning. 


test set: See test suite. 

testmangd: Se testsvit. 


test situation: See test condition. 

testomstandigheter: Se testvillkor. 


test specification: A document that consists of a test 
design specification, test case specification and/or test 
procedure specification. 

testspecifikation: Ett dokument som bestar av en 
testdesignspecifikation, testfallsspecifikation 
och/eller testprocedurspecifikation 


test specification technique: See test design technique. 

testspecifikationsteknik: Se testdesignteknik. 


test stage: See test level. 

teststeg: Se testniva. 

F 

ATM 

ATA 

ETM 

test strategy: A high-level description of the test levels to 
be performed and the testing within those levels for an 
organization or programme (one or more projects). 

teststrategi: En hognivabeskrivning av de nivaer som 
skall testas och hur testningen skall ga till i dessa 
nivaer inom ett eller fler projekt. 


82 




















\£>t 

\/s 

▼ Ti 


SSTB 


Swedish Software 
Testing Board 


F 

test suite: A set of several test cases for a component or 
system under test, where the post condition of one test is 
often used as the precondition for the next one. 

testsvit: Ett antal testfall for en komponent eller ett 
system, dar utdata fran ett testfall ofta anvands som 
forutsattningfor nasta. 

F 

ATM 

test summary report: A document summarizing testing 

activities and results. It also contains an evaluation of the 

corresponding test items against exit criteria. [After IEEE 
829] 

slutlig testrapport: Ett dokument som summerar 

testaktiviteteroch resultat. Det innehallerocksa en 

utvardering av motsvarande testelement jamfort 
med avslutskriterier. [Efter IEEE 829] 


test target: A set of exit criteria. 

testmal: En mangd av avslutskriterier. 


test technique: See test design technique. 

testteknik: Se testdesignteknik. 

EITP 

test tool: A software product that supports one or more 
test activities, such as planning and control, specification, 
building initial files and data, test execution and test 
analysis. [TMap] See also CAST. 

testverktyg: Ett system eller program vars syfte ar 
att underlatta testning. 


test type: A group of test activities aimed at testing a 
component or system focused on a specific test objective, 
i.e. functional test, usability test, regression test etc. A test 
type may take place on one or more test levels or test 
phases. [After TMap] 

testtyp: aven testsort, typ av test, testgrupp. 
Gruppering av testfall efter sort eller typ av testning 
som testfallen utfor, av en viss kvalitet eller attribut, 
t.ex. granssnittstest, regressionstest, robusthetstest. 
Grupperingen ar oberoende av testfas och testniva. 
[Efter TMap] 

ATT 

testability: The capability of the software product to 
enable modified software to be tested. [ISO 9126] See also 
maintainability. 

testbarhet: Kapaciteten hos programvaruprodukten 
att tillata andrad programvara att kunna testas. [ISO 
9126] Se aven underhallbarhet. 


testability review: A detailed check of the test basis to 
determine whether the test basis is at an adequate quality 
level to act as an input document for the test process. 

[After TMap] 

testbarhetsgranskning: En detaljerad kontroll av 

testbasen for att bestamma om den har en 
tillfredsstallande kvalitet for att tjanstgora som 
indokumenttill testprocessen. [Efter TMap] 


testable requirement: A requirements that is stated in 
terms that permit establishment of test designs (and 
subsequently test cases) and execution of tests to 
determine whether the requirement has been met. [After 
IEEE 610] 

testbara krav: Krav som ar skrivna pa sadant satt att 
de mojliggdr etablering av testdesign (och darefter 
testfall) samt exekvering av tester for att kontrollera 
om kraven har blivit uppfyllda. [Efter IEEE 610] 

F 

tester: A skilled professional who is involved in the testing 
of a component or system. 

testare: En person med ratt kompetens for 
aktiviteten som ar involverad i testningen av en 
komponent eller ett system. 

F 

testing: The process consisting of all lifecycle activities, 
both static and dynamic, concerned with planning, 
preparation and evaluation of software products and 
related work products to determine that they satisfy 
specified requirements, to demonstrate that they are fit 
for purpose and to detect defects. 

testning: Process som omfattar alia 
livscykelaktiviteterforen programvaruprodukt, bade 
statiska och dynamiska, samt behandlar planering, 
forberedelse och utvardering av 
programvaruprodukterfor att avgora om de 
uppfyller specificerade krav, for att demonstrera att 
de ar klara for anvandning och for att hitta fel. 
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F 

testware: Artifacts produced during the test process 
required to plan, design, and execute tests, such as 
documentation, scripts, inputs, expected results, set-up 
and clear-up procedures, files, databases, environment, 
and any additional software or utilities used in testing. 

[After Fewster and Graham] 

testvara: aven testartiklar, testartefakter. De 
artefakter (producerade under testprocessen) som 
kravs for att planera, designa och exekvera test. 
Exempel pa testartiklar ar dokumentation, skript, 
indata, forvantade resultat, databaser, testmiljo och 
andra programvaror eller produkter som anvants i 
testningen. [Efter Fewster and Graham] 


thread testing: An approach to component integration 
testing where the progressive integration of components 
follows the implementation of subsets of the 
requirements, as opposed to the integration of 
components by levels of a hierarchy. 

tradtestning: En variant av 

komponentintegrationstestning, dar den progressiva 
integrationen av komponenterfoljer 
implementationen av delmangderav krav, i motsats 
till integrationen av komponenter i hierarkiska 

nivaer. 


three point estimation: A test estimation method using 
estimated values for the "best case", "worst case", and 
"most likely case" of the matter being estimated, to define 
the degree of certainty associated with the resultant 

estimate. 

trepunktsestimering: En testestimeringsmetod som 
anvander estimerade varden for "basta fall", "varsta 
fall" och "mesttroligafall" rorande det som 
estimeras, for att definiera graden av sakerhet 

rorande det erhallna estimatet. 


time behavior: See performance. 

tidsupptradanden: Se prestanda. 

ATM 

EITP 

TMMi: See Test Maturity Model integration. 

TMMi: Se Test Maturity Model integration. 


top-down testing: An incremental approach to integration 
testing where the component at the top of the component 
hierarchy is tested first, with lower level components 
being simulated by stubs. Tested components are then 
used to test lower level components. The process is 
repeated until the lowest level components have been 
tested. See also integration testing. 

uppifran och ner-testning: aven top-down-testning. 

En inkrementell integrationstestteknik, dar 
komponenterna pa den hogsta nivan testas forst 
med simulering av lagnivakomponenter med hjalp av 
stubbar. De testade komponenterna anvands sedan 
for att testa lagnivakomponenterna. Processen 
upprepas tills alia lagnivakomponenter hartestats. 

Jmf nerifran och upp-testning. Se aven 
integrationstestning. 

EITP 

Total Quality Management: An organization-wide 
management approach centered on quality, based on the 
participation of all members of the organization and 
aiming at longterm success through customer satisfaction, 
and benefits to all members of the organization and to 
society. Total Quality Management consists of planning, 
organizing, directing, control, and assurance. [After ISO 
8402] 

Total Quality Management: En ledningsfilosofi som 
fokuserar pa kvalitet i hela organisationen och som 
bygger pa att alia medarbetare deltar. Malet ar att 
uppna langsiktigframgang dels genom nojda kunder 
och dels genom att gagna organisationen och 
samhallet. Total Quality Management bestarav 
aktiviteterna planering, organisering, vagledning, 
styrning och forsakring. [Efter ISO 8402] 

EITP 

TPG: See Test Process Group. 

TPG: Se Test Process Group. 

ATM 

EITP 

TPI Next: A continuous business-driven framework for test 

process improvement that describes the key elements of 
an effective and efficient test process. 

TPI Next: Ett fortldpande affarsdrivet ramverkfor 
testprocessforbattring som beskriver 
nyckelelementen i en andamalsenlig och effektiv 
testprocess. 
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EITP 

TQM: See Total Quality Management. 

TQM: Se Total Quality Management. 

F 

traceability: The ability to identify related items in 
documentation and software, such as requirements with 
associated tests. See also horizontal traceability, vertical 
traceability. 

sparbarhet: Mojligheten att identifiera relaterade 
element i dokumentation och programvara, som 
t.ex. systemkrav, med tillhorande tester. Se aven 
horisontell sparbarhet, vertikal sparbarhet. 


traceability matrix: A two-dimensional table, which 
correlates two entities (e.g., requirements and test cases). 
The table is used to determine and achieve coverage, to 
trace back and forth from one entity to the other, and to 
assess the impact of proposed changes. 

sparbarhetsmatris: En tvadimensionell tabell vilken 
visar sambandet mellan tva entiteter (t.ex. krav och 
testfall). Tabellen anvands for att faststalla och 
uppna tackning, for att spara framat och bakat fran 
en entitet till en annan, och for att bedoma paverkan 
avforeslagna andringar. 

EITP 

transactional analysis: The analysis of transactions 
between people and within people's minds; a transaction 
is defined as a stimulus plus a response. Transactions take 
place between people and between the ego states 
(personality segments) within one person's mind. 

transaktionsanalys: Analys av transaktioner mellan 
manniskor och internt inom en persons medvetande. 
En transaktion harformen av ett stimulus-respons- 
par. Transaktioner sker mellan manniskor och mellan 
s.k. egotillstand (personlighetssegment) internt inom 
en persons medvetande. 

EITP 

transcendent-based quality: A view of quality, wherein 
quality cannot be precisely defined, but we know it when 
we see it, or are aware of its absence when it is missing. 
Quality depends on the perception and affective feelings 
of an individual or group of individuals towards a product. 
[After Garvin] See also manufacturing-based quality, 
product-based quality, user-based quality, value-based 
quality. 

kanslobaserad kvalitet: Ett satt att se pa kvalitet 
som innebar att kvalitet inte kan definieras pa ett 
exakt satt, trots det kan vi anda avgora om kvaliteten 
hos en produkt nar vi ser den. 1 detta synsatt beror 
kvaliteten pa uppfattning och de kanslorsom 
produkten vacker hos en individ eller en grupp av 
individer. [Efter Garvin] Se aven anvandarbaserad 
kvalitet, produktbaserad kvalitet, 
tillverkningsbaserad kvalitet och vardebaserad 
kvalitet. 


U 


ATA 

understandability: The capability of the software product 

to enable the user to understand whether the software is 

suitable, and how it can be used for particular tasks and 
conditions of use. [ISO 9126] See also usability. 

forstaelighet: Programvaruproduktens kapacitet att 
hjalpa anvandaren attforsta huruvida programvaran 
ar andamalsenlig och hur den kan anvandas for 
speciella uppgifter och villkor. [ISO 9126] Se aven 

anvandbarhet. 


unit: See component. 

enhet: Se komponent. 

F 

unit test framework: A tool that provides an environment 
for unit or component testing in which a component can 

be tested in isolation or with suitable stubs and drivers. It 

also provides other support for the developer, such as 
debugging capabilities. [Graham] 

enhetstestramverk: Ett verktyg som erbjuder en 
miljo for en komponent eller enhet, sa att den kan 
testas enskilt eller med lampliga stubbar eller 
drivrutiner. Ramverket erbjuder ocksa stod for 
utvecklaren, i form av t.ex. avlusningsmojligheter. 
[Graham] 


unit testing: See component testing. 

enhetstestning: Se komponenttestning. 
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unreachable code: Code that cannot be reached and 

therefore is impossible to execute. 

onabar kod: Kod som inte kan nas och darfor ar 
omojlig att exekvera. 


usability: The capability of the software to be understood, 
learned, used and attractive to the user when used under 
specified conditions. [ISO 9126] 

anvandbarhet: Programvarans kapacitetattforstas, 
laras in, anvandas av och vara attraktiv for 
anvandaren nar den anvands under specificerade 
forhallanden [ISO 9126] 

F 

ATA 

usability testing: Testing to determine the extent to which 
the software product is understood, easy to learn, easy to 
operate and attractive to the users under specified 
conditions. [After ISO 9126] 

anvandbarhetstestning: Testning av hur svar en 
produkt ar att lara sig anvanda och om produkten 
loser den uppgift den ar avsedd att losa. [Efter ISO 
9126] 


use case: A sequence of transactions in a dialogue 
between an actor and a component or system with a 
tangible result, where an actor can be a user or anything 
that can exchange information with the system. 

anvandningsfall: En sekvens av transaktioner i en 
dialog mellan en aktor och en komponent eller ett 
system med ett verkligt resultat, dar en aktor kan 
vara en anvanda re eller en godtycklig entitet som 
kan utbyta information med systemet. 

Kommentar: Varje anvandningsfall har 
forutsattningar, som skall vara uppfyllda for att 
anvandningsfallet skall fungera korrekt. Dessutom 
avslutas varje anvandningsscenario med sluttillstand, 
vilka ar de observerbara resultaten och det slutgiltiga 
tillstandet hos systemet da scenariot ar exekverat. 

F 

ATA 

use case testing: A black box test design technique in 
which test cases are designed to execute scenarios of use 

anvandningsfallsbaserad testning: En black-box- 
testdesignteknik dar testfall designas for att 
exekvera anvandningsfall. 

F 

user acceptance testing: See acceptance testing. 

anvandaracceptanstestning: Se acceptanstestning. 


user scenario testing: See use case testing 

testning utifran anvandarscenarion: Se 

anvandningsfallsbaserad testning. 


user story: A high-level user or business requirement 
commonly used in agile software development, typically 
consisting of one or more sentences in the everyday or 
business language capturing what functionality a user 
needs, any non-functional criteria, and also includes 
acceptance criteria. See also agile software development, 
requirement. 

anvandarberattelse : Ett anvandar- eller 

verksamhetskrav pa hog niva. Vanligtforekommande 
i agil mjukvaruutveckling, vanligen bestaende av en 
eller flera meningar i vardagligt eller affarssprak som 
fangar den funktionalitet en anvandare behover, 

icke-funktionella kriterieroch som aven innehaller 

acceptanskriterier. Se aven agil mjukvaruutveckling, 
krav. 

ATA 

user story testing: A black box test design technique in 
which test cases are designed based on user stories to 
verify their correct implementation. See also user story. 

anvandarberattelse-testning: En black-box-teknik 
dar testfallen ar designade baserade pa 

anvandarberattelser for att verifiera att de 

implementerats korrekt. Se aven 
anvandarberattelse. 
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user test: A test whereby real-life users are involved to 
evaluate the usability of a component or system. 

anvandartest: Tester dar anvandare fran aktuell 

verksamhet ar inblandade for att utvardera 

anvandbarheten hos komponenten eller systemet. 

EITP 

user-based quality: A view of quality, wherein quality is 
the capacity to satisfy needs, wants and desires of the 
user(s). A product or service that does not fulfill user 
needs is unlikely to find any users. This is a context 
dependent, contingent approach to quality since different 
business characteristics require different qualities of a 
product, [after Garvin] See also manufacturing-based 
quality, product-based quality, transcendent-based 
quality, valuebased quality. 

anvandarbaserad kvalitet: Ett satt att se pa kvalitet 
som innebar att kvaliteten hos en produkt definieras 
av produktens formaga att uppfylla anvandarens 
behov och onskningar. En produkt som inte uppfyller 
anvandarnas behov kommer troligtvis inte att ha 
nagra anvandare. Denna vy av kvalitet ar kontext och 
tillfallighetsberoende eftersom olika 
affarssituationer kraver olika egenskaper hos en 
produkt. [Efter Garvin] Se aven produktbaserad 
kvalitet, tillverkningsbaserad kvalitet, upplevd 

kvalitet och vardebaserad kvalitet. 


V 


F 

validation: Confirmation by examination and through 
provision of objective evidence that the requirements for 
a specific intended use or application have been fulfilled. 
[ISO 9000] 

validering: Bekraftelse genom undersokning och 
genom framlaggande av sakliga bevis for att kraven 
for en specifikt avsedd anvandning eller specifik 
tillampning har uppfyllts. [ISO 9000] 

EITP 

value-based quality: A view of quality, wherein quality is 
defined by price. A quality product or service is one that 
provides desired performance at an acceptable cost. 

Quality is determined by means of a decision process with 
stakeholders on trade-offs between time, effort and cost 
aspects. [After Garvin] See also manufacturing-based 
quality, productbased quality, transcendent-based quality, 
user-based quality. 

vardebaserad kvalitet: Ett satt att se pa kvalitet som 
innebar att kvaliteten hos en produkt avgors av 
produktens pris. Produkter eller tjanster ar av hog 
kvalitet om de tillhandahaller onskad prestanda for 
en acceptabel kostnad. Kvaliteten hos en produkt 
avgors i form av en beslutsprocess hos en intressent 
dar tids, anstrangnings och kostnadsaspekter vags 
motvarandra. [Efter Garvin] Se aven 
anvandarbaserad kvalitet, produktbaserad kvalitet, 
tillverkningsbaserad kvalitet och upplevd kvalitet. 


variable: An element of storage in a computer that is 
accessible by a software program by referring to it by a 

name. 

variabel: En namngiven lagringsplats i en datorsom 
ar nabar av en programvara genom att programmet 
refererartill namnet pa lagringsplatsen. 

F 

verification: Confirmation by examination and through 
provision of objective evidence that specified 
requirements have been fulfilled. [ISO 9000] 

verifiering: Bekraftelse genom undersokning och 
genom framlaggande av sakliga bevis for att 
specificerade krav har uppfyllts. [ISO 9000] 

F 

version control: See configuration control. 

versionshantering: Se konfigurationskontroll. 


vertical traceability: The tracing of requirements through 
the layers of development documentation to components. 

vertikal sparbarhet: Sparning av krav genom lager av 
utvecklingsdokumentation nertill komponenter. 
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F 

V-model: A framework to describe the software 

development lifecycle activities from requirements 
specification to maintenance. The V-model illustrates how 
testing activities can be integrated into each phase of the 
software development lifecycle. 

V-modell: Ett ramverk som beskriver aktiviteterna 
inom programvaruutveckling. V-modellen beskriver 
ur ett testperspektiv hur testaktiviteter kan 
integreras i varje fas av livscykeln for 
programvaruutveckling. 


volume testing: Testing where the system is subjected to 
large volumes of data. See also resource-utilization 
testing. 

volymtestning: Testning dar systemet utsatts for 
hantering av stora datavolymer. Se aven 
resursanvandningstestning. 


W 


F 

ATM 

walkthrough: A step-by-step presentation by the author 
of a document in order to gather information and to 
establish a common understanding of its content. 

[Freedman and Weinberg, IEEE 1028] See also peer 

review. 

genomgang: En steg-for-steg-presentation utford av 
forfattaren till ett dokument med syfte att samla 
information och ska pa en gemensam forstaelse av 
innehallet. [Freedman and Weinberg, IEEE 1028] Se 
aven kollegial granskning. 

ATA 

WAMMI: See Website Analysis and MeasureMent 

Inventory. 

WAMMI: Se Website Analysis and MeasureMent 
Inventory. 


WBS: See Work Breakdown Structure. 

WBS: Se Work Breakdown Structure. 

ATA 

Website Analysis and MeasureMent Inventory (WAMMI): 

A questionnaire-based usability test technique for 
measuring web site software quality from the end user's 
point of view. 

Website Analysis and MeasureMent Inventory 
(WAMMI): En enkatbaserad testteknik inom 

anvandbarhet for att bedoma webbsidors 
mjukvarukvalitet ur ett slutanvandarperspektiv. 

ATA 

white-box technique: See white-box test design 
technique. 

white-box-teknik: Se white-box-testdesignteknik. 

F 

ATT 

white-box test design technique: Procedure to derive 
and/or select test cases based on an analysis of the 
internal structure of a component or system. 

white-box-testdesignteknik: Procedur for att 
harleda och/eller valja testfall baserat pa en analys 
av den interna strukturen hos en komponent eller 
ett system. 

F 

white-box testing: Testing based on an analysis of the 
internal structure of the component or system. 

white-box-testning: Testning baserad pa analys av 
den interna strukturen hos en komponent eller ett 
system. 

ATM 

Wide Band Delphi: An expert based test estimation 
technique that aims at making an accurate estimation 
using the collective wisdom of the team members. 

Wide Band Delphi: En testberakningsteknik som ar 
baserad pa expertis med malsattning att gora en 
exakt (eller noggrann) uppskattning genom alia 
teammedlemmars gemensamma kompetens. 

ATT 

wild pointer: A pointer that references a location that is 
out of scope for that pointer or that does not exist. See 
also pointer. 

wild pointer: En pekare som refererartill en plats 
utanforomradesgranserfor pekaren eller till en plats 
som inte finns. Se aven pekare. 
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Work Breakdown Structure: An arrangement of work 
elements and their relationship to each other and to the 
end product. [CMMI] 


Work Breakdown Structure: Ett satt att beskriva 
arbetsmoment, deras forhallande till varandra och 
till den slutliga produkten. [CMMI] 
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